Brackets and the Invention of CSS
dorayme
to leave us with the legacy of the curly brackets (for which one
has to shift press) rather than the square (for which one simply
has to press)?
p [margin: 0;]
is two key presses shorter then
p {margin: 0;}
Multiply that by a few billion over the world of css, taking in
to account a lot of consequences including the bigger chance of
typos and revisions, the greater expenditure of energy on people
and processors, more wear and tear on the keyboard.
--
dorayme
Jonathan N. Little
Square brackets are for attribute selectors. A useful but not often used
feature because of IE.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
dorayme
"Jonathan N. Little" <lws...@centralva.net> wrote:
> dorayme wrote:
> > Is there some particular reason that the inventors of CSS chose
> > to leave us with the legacy of the curly brackets (for which one
> > has to shift press) rather than the square (for which one simply
> > has to press)?
> >
> > p [margin: 0;]
> >
> > is two key presses shorter then
> >
> > p {margin: 0;}
> >
> > Multiply that by a few billion over the world of css, taking in
> > to account a lot of consequences including the bigger chance of
> > typos and revisions, the greater expenditure of energy on people
> > and processors, more wear and tear on the keyboard.
> >
>
> Square brackets are for attribute selectors. A useful but not often used
> feature because of IE.
So... are you are implying perhaps that it was anticipated that
the square brackets would have been used more often?
--
dorayme
Sander Tekelenburg
<doraymeRidThis-22C...@news-vip.optusnet.com.au>,
dorayme <dorayme...@optusnet.com.au> wrote:
> Is there some particular reason that the inventors of CSS chose
> to leave us with the legacy of the curly brackets (for which one
> has to shift press) rather than the square (for which one simply
> has to press)?
Perhaps to build upon existing conventions. Perhaps on some keyboards
square brackets actually are harder to type. Perhaps they tossed a coin.
> p [margin: 0;]
>
> is two key presses shorter then
>
> p {margin: 0;}
So is p {margin:0}
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Chris F.A. Johnson
>
>
> Is there some particular reason that the inventors of CSS chose
> to leave us with the legacy of the curly brackets (for which one
> has to shift press) rather than the square (for which one simply
> has to press)?
>
> p [margin: 0;]
>
> is two key presses shorter then
>
> p {margin: 0;}
It's only one key press shorter for me; when I press { in a .css
file, the closing brace is automatically inserted.
> Multiply that by a few billion over the world of css, taking in
> to account a lot of consequences including the bigger chance of
> typos and revisions, the greater expenditure of energy on people
> and processors, more wear and tear on the keyboard.
>
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Sherman Pendley
> Is there some particular reason that the inventors of CSS chose
> to leave us with the legacy of the curly brackets (for which one
> has to shift press) rather than the square (for which one simply
> has to press)?
I suspect it's a question of familiarity - JavaScript, C, Perl, and
many other languages with which many web developers may be familiar
all use curly brackets.
By contrast, not too many devs are writing web apps in SmallTalk or
Objective-C. Even fewer than there once were, no thanks to Apple. :-(
[ObjC retain];
sherm--
--
WV News, Blogging, and Discussion: http://wv-www.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
dorayme
Sander Tekelenburg <us...@domain.invalid> wrote:
> In article
> <doraymeRidThis-22C...@news-vip.optusnet.com.au>,
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > Is there some particular reason that the inventors of CSS chose
> > to leave us with the legacy of the curly brackets (for which one
> > has to shift press) rather than the square (for which one simply
> > has to press)?
>
> Perhaps to build upon existing conventions.
Which were?
> Perhaps on some keyboards
> square brackets actually are harder to type.
Well, that is a question, I might be seeing a biassed sample here
in Australia?
>
> > p [margin: 0;]
> >
> > is two key presses shorter then
> >
> > p {margin: 0;}
>
> So is p {margin:0}
How do you figure this? And what is its relevance?
--
dorayme
dorayme
"Chris F.A. Johnson" <cfajo...@gmail.com> wrote:
> On 2007-11-24, dorayme wrote:
> >
> >
> > Is there some particular reason that the inventors of CSS chose
> > to leave us with the legacy of the curly brackets (for which one
> > has to shift press) rather than the square (for which one simply
> > has to press)?
> >
> > p [margin: 0;]
> >
> > is two key presses shorter then
> >
> > p {margin: 0;}
>
> It's only one key press shorter for me; when I press { in a .css
> file, the closing brace is automatically inserted.
>
I vaguely recall something like this on this winbox I fire up now
and then (in a pgm called Topstyle). Similar perhaps is BBEdit's
built in control + 1 getting <h1></h1> with the cursor seemingly
conveniently in between. All very well in a way. There are
drawbacks of course: you are typing away and you want a level one
heading and quickly realise it is a level 2 you want, oops... you
have to change two numbers. The normal typing way of putting the
opening tag would give you a chance (if you realise just after
typing the first 1) to merely back space on and carry on.
That reminds me, there is a whole lot of shifting going on for
for < and the greater than. But in this case, the inventors could
hardly have chosen instead the "," and "."
Perhaps a special html/css board is needed. <g>
> > Multiply that by a few billion over the world of css, taking in
> > to account a lot of consequences including the bigger chance of
> > typos and revisions, the greater expenditure of energy on people
> > and processors, more wear and tear on the keyboard.
> >
--
dorayme
dorayme
Sherman Pendley <spam...@dot-app.org> wrote:
> dorayme <dorayme...@optusnet.com.au> writes:
>
> > Is there some particular reason that the inventors of CSS chose
> > to leave us with the legacy of the curly brackets (for which one
> > has to shift press) rather than the square (for which one simply
> > has to press)?
>
> I suspect it's a question of familiarity - JavaScript, C, Perl, and
> many other languages with which many web developers may be familiar
> all use curly brackets.
Yes, I suspect this is probably the direct or indirect
motivation. I recall programming in Microsoft QuickBasic on a Mac
SE and there were few brackets involved and when they were they
were round or square (Remember those days Sherm?). Oddly enough I
forget about the later FutureBasic which I had to move to with
the PowerPC chip... I suppose Javascript and C and Perl are very
old compared to CSS...
--
dorayme
Ben C
> In article <user-1DA0ED.0...@textnews.euro.net>,
> Sander Tekelenburg <us...@domain.invalid> wrote:
>
>> In article
>> <doraymeRidThis-22C...@news-vip.optusnet.com.au>,
>> dorayme <dorayme...@optusnet.com.au> wrote:
>>
>> > Is there some particular reason that the inventors of CSS chose
>> > to leave us with the legacy of the curly brackets (for which one
>> > has to shift press) rather than the square (for which one simply
>> > has to press)?
>>
>> Perhaps to build upon existing conventions.
>
> Which were?
It's common in programming languages for {} to go around bigger blocks
of stuff consisting of a few lines or more.
C, Tcl, Java, JavaScript, Perl, and Ruby are all examples where this is
the case.
I think you'd tend to use {} even when writing on paper with a pencil
for large blocks of stuff. So maybe that's where it comes from. () is
used in expressions like (2+3)*5, [] usually for array and/or dictionary
access, like a[2] or a["foo"], and {} to enclose several lines at a
time.
Ben C
BASIC usually uses something like this:
if
bla blah
bla bla
endif
i.e. keywords mark the end of blocks, so you don't need {}. C and others
don't bother with endif. You just put everything after "if" in a block
delimited with {}.
It may relate to the way a traditional BASIC interpreter works-- pretty
much one line at a time without much in the way of parsing first, and
with the requirement that each line start with a keyword. Hence all
those pointless keywords like "LET" and "DIM".
Johannes Koch
> Is there some particular reason that the inventors of CSS chose
> to leave us with the legacy of the curly brackets (for which one
> has to shift press) rather than the square (for which one simply
> has to press)?
On my (german) keyboard, I have to press AltGr + 8 for a square bracket
('[') and AltGr + 7 for a curly bracket ('{'). Maybe it's similar on a
norwegian keyboard.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
Joshua Cranmer
First, the shift key doesn't really count in my book as an extra key
press. Even if you want to count it, I generally type '{}' and then
reformat the internals anyways, so it's only one extra keystroke.
Anyways, this dates back to a long history of programming languages,
starting with BCPL, upon which it migrated to B, C, C++, Java,
Javascript/ECMAScript, PHP, Perl, C#, D, etc. The most prevalent
non-curly bracket and non-scripted language is in fact FORTRAN, which is
due to its extreme age.
Many web developers would have been used to using this syntax of curly
braces for other branches of development (most notably Javascript or
PHP), and would feel most at home with this type of syntax. Had the
square brackets been used, I would be cursing whomever had come up with
that.
Alternatively, once can look at their usage outside of programming. The
square brackets are used most often to denote short, auxiliary
information, and curly ones, when used, typically denote a choice among
many objects, and would bracket more material. Also, in math, the
parenthesis order is as follows: 9/{7/[3^(1/2)]}. Curly braces tend to
bracket more information than square ones, so choosing the curly brace
as the top-level bracketing scheme in CSS makes sense in this regard.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Klaus Krtschil
There a lot of different keyboards in use. On my keyboard I have to
press AltGr to access the { and [ characters...
Klaus
--
Linux User #54760
Sander Tekelenburg
<doraymeRidThis-F15...@news-vip.optusnet.com.au>,
dorayme <dorayme...@optusnet.com.au> wrote:
> In article <user-1DA0ED.0...@textnews.euro.net>,
> Sander Tekelenburg <us...@domain.invalid> wrote:
>
> > In article
> > <doraymeRidThis-22C...@news-vip.optusnet.com.au>,
> > dorayme <dorayme...@optusnet.com.au> wrote:
[...]
> > Perhaps on some keyboards
> > square brackets actually are harder to type.
>
> Well, that is a question, I might be seeing a biassed sample here
> in Australia?
Perhaps. I don't think I've ever seen a typical australian keybaord, if
such a thing exists. I'm assuming it's much like a 'typical' USA-ian
keyboard. From what I've seen, many european keyboards are quite
different (also amongst each other) from what appears to be common in
the USA. Those keyboards often provide single keys for often used
charcaters with accents, umlauts, ligatures, etc. at the cost of single
key access for other 'special characters', like brackets and such. If
you generally need an u-umlaut once every sentence, you'll want a single
key for that. (ASCII covers only 2 of the world's languages.)
And that's only looking at the relatively small minority that uses the
roman script. I expect that in the rest of the world there are even many
more and wildlier different keyboards in common use.
> > > p [margin: 0;]
> > >
> > > is two key presses shorter then
> > >
> > > p {margin: 0;}
> >
> > So is p {margin:0}
>
> How do you figure this? And what is its relevance?
You seemed to complain about having to press too many keys, yet were
using a space and a semi-colon where they aren't necessary. (Whether
those in fact do require two key presses, or more, or less, of course
depends on the keyboard and the development environment you use ;))
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
Sherman Pendley
> In article <m1fxywn...@dot-app.org>,
> Sherman Pendley <spam...@dot-app.org> wrote:
>
>> dorayme <dorayme...@optusnet.com.au> writes:
>>
>> > Is there some particular reason that the inventors of CSS chose
>> > to leave us with the legacy of the curly brackets (for which one
>> > has to shift press) rather than the square (for which one simply
>> > has to press)?
>>
>> I suspect it's a question of familiarity - JavaScript, C, Perl, and
>> many other languages with which many web developers may be familiar
>> all use curly brackets.
>
> Yes, I suspect this is probably the direct or indirect
> motivation. I recall programming in Microsoft QuickBasic on a Mac
> SE and there were few brackets involved and when they were they
> were round or square (Remember those days Sherm?).
Yep. I was writing GWBasic and Turbo Pascal for PCs back then. They didn't
have many brackets either. I kind of miss those days, a little bit anyway.
Programming was all about inventing new kinds of apps. Now it's just shaving
10 more seconds off the TPS Report Wizard to save our corporate masters a
few pennies.
I think that's part of the reason so many folks are into open-source these
days. It's the only way to have any fun as a programmer - writing code for
sale is just plain old boring work, complete with pointy-haired bosses and
office politics.
Harlan Messinger
Absolutely, many web designers would love to be able to use
attribute-based selectors. Also, the use of square brackets for
attribute-based selectors is consistent with the notation used in XPath.
Jonathan N. Little
If we had use of attribute selectors it could eliminate the need of many
classes peppered throughout the markup. (So as designers let's give
MS the ol' 1-fingered-salute right back!)
Chris F.A. Johnson
> "Chris F.A. Johnson" <cfajo...@gmail.com> wrote:
>> On 2007-11-24, dorayme wrote:
>> >
>> >
>> > Is there some particular reason that the inventors of CSS chose
>> > to leave us with the legacy of the curly brackets (for which one
>> > has to shift press) rather than the square (for which one simply
>> > has to press)?
>> >
>> > p [margin: 0;]
>> >
>> > is two key presses shorter then
>> >
>> > p {margin: 0;}
>>
>> It's only one key press shorter for me; when I press { in a .css
>> file, the closing brace is automatically inserted.
>
> I vaguely recall something like this on this winbox I fire up now
> and then (in a pgm called Topstyle). Similar perhaps is BBEdit's
> built in control + 1 getting <h1></h1> with the cursor seemingly
> conveniently in between. All very well in a way. There are
> drawbacks of course: you are typing away and you want a level one
> heading and quickly realise it is a level 2 you want, oops... you
> have to change two numbers. The normal typing way of putting the
> opening tag would give you a chance (if you realise just after
> typing the first 1) to merely back space on and carry on.
I'd just press Undo and enter the one I wanted.
dorayme
Joshua Cranmer <Pidg...@verizon.invalid> wrote:
> dorayme wrote:
> > Is there some particular reason that the inventors of CSS chose
> > to leave us with the legacy of the curly brackets (for which one
> > has to shift press) rather than the square (for which one simply
> > has to press)?
> >
> > p [margin: 0;]
> >
> > is two key presses shorter then
> >
> > p {margin: 0;}
> >
> > Multiply that by a few billion over the world of css, taking in
> > to account a lot of consequences including the bigger chance of
> > typos and revisions, the greater expenditure of energy on people
> > and processors, more wear and tear on the keyboard.
>
> First, the shift key doesn't really count in my book as an extra key
> press.
> Anyways, this dates back to a long history of programming languages,
> starting with BCPL, upon which it migrated to B, C, C++, Java,
> Javascript/ECMAScript, PHP, Perl, C#, D, etc. The most prevalent
> non-curly bracket and non-scripted language is in fact FORTRAN, which is
> due to its extreme age.
>
> Many web developers would have been used to using this syntax of curly
> braces for other branches of development (most notably Javascript or
> PHP), and would feel most at home with this type of syntax. Had the
> square brackets been used, I would be cursing whomever had come up with
> that.
>
> Alternatively, once can look at their usage outside of programming. The
> square brackets are used most often to denote short, auxiliary
> information, and curly ones, when used, typically denote a choice among
> many objects, and would bracket more material. Also, in math, the
> parenthesis order is as follows: 9/{7/[3^(1/2)]}. Curly braces tend to
> bracket more information than square ones, so choosing the curly brace
> as the top-level bracketing scheme in CSS makes sense in this regard.
These are very good points and surely sum up.
[On counting the shift as a keypress: for a start, you absolutely
need a second hand. <g>]
--
dorayme
dorayme
Sander Tekelenburg <us...@domain.invalid> wrote:
> dorayme wrote:
>
> > > Perhaps on some keyboards
> > > square brackets actually are harder to type.
> >
> > Well, that is a question, I might be seeing a biassed sample here
> > in Australia?
>
> Perhaps. I don't think I've ever seen a typical australian keybaord,
Likely to be same as in UK and other Commonwealth countries.
> > > > p [margin: 0;]
> > > >
> > > > is two key presses shorter then
> > > >
> > > > p {margin: 0;}
> > >
> > > So is p {margin:0}
> >
> > How do you figure this? And what is its relevance?
>
> You seemed to complain about having to press too many keys, yet were
> using a space and a semi-colon where they aren't necessary.
Ah! <g> (... but really we are talking cost-benefit here)
Actually, it has given me the thought to look at programming keys
on a board to be used for html/css work that may better suit me.
I often use just one hand for adjustment work. (In case you were
wondering, the other hand is most often engaged in warding off
enemies - think Rugby...)
--
dorayme
dorayme
Harlan Messinger <hmessinger...@comcast.net> wrote:
> dorayme wrote:
> > In article <4d20a$4747a6f9$40cba7b4$15...@NAXS.COM>,
> > "Jonathan N. Little" <lws...@centralva.net> wrote:
> >
...
> >> Square brackets are for attribute selectors. A useful but not often used
> >> feature because of IE.
> >
> > So... are you are implying perhaps that it was anticipated that
> > the square brackets would have been used more often?
>
> Absolutely, many web designers would love to be able to use
> attribute-based selectors.
My very last query was meant to be more specific than perhaps it
sounded. It was not just:
(1) Are you are implying that it was anticipated that the square
brackets would have been used more often than they has turned out
to have been used?
but
(2) Are you are implying perhaps that it was anticipated that
the square brackets would have been used more often than the
curly ones?
--
dorayme
Jonathan N. Little
> [On counting the shift as a keypress: for a start, you absolutely
> need a second hand. <g>]
>
Must be a Mac minimalist-thinking thing, like that one-button mouse! ;-)
Harlan Messinger
You might well ask whether it was anticipated, but whether or not it
was, it's clear to me that Jonathan's response didn't imply it. All he
did was point out that they were already dedicated to another purpose.
And it isn't apparent to me that minimizing use of the shift key is
typically a consideration in designing *any* notation. After all, HTML
and XML live and die by the shift-loving less-than and greater-than
characters!
dorayme
"Jonathan N. Little" <lws...@centralva.net> wrote:
> dorayme wrote:
>
> > [On counting the shift as a keypress: for a start, you absolutely
> > need a second hand. <g>]
> >
>
> Must be a Mac minimalist-thinking thing, like that one-button mouse! ;-)
Actually, I was wrong, not "absolutely at all". Sorry. There are
two shift keys and one *can* use the right one and bracket key
with one hand. But! There is an energy cost and it involves the
movement of the thumb in an unnatural manner (as if to fold it
onto the palm of the hand) so that it engages that shift while
the fore or middle finger does the bracket key. This is RSI
territory.
I have to say, Jonathan that I find it very awkward to alt C (and
V) on your keyboard, Command and C (or V) on a Mac are closer
together.
As for this million button mouse business, never felt the need
for more than one button - except if you count the scroll wheel.
Now a scroll wheel is something I have missed on my Mac just
after I have used my winbox and the MS Intellimouse.
(Apple have one out with a minimalistic nipple for a wheel, I am
not that keen on it now that I tried it recently. A wheel is a
wheel! Actually Jonathan, I am just right now about to develop a
pedal mouse that can take over scrolling. If you would like to
invest in the development, please send at least $10. Could become
really big. A wireless pedal mouse from downunder. Don't rush in,
think about it a while.)
--
dorayme
dorayme
Harlan Messinger <hmessinger...@comcast.net> wrote:
You are not wrong about this! I will now settle back into simple
acceptance of the situation. <g>
--
dorayme
Ben Bacarisse
> dorayme wrote:
>> Is there some particular reason that the inventors of CSS chose to
>> leave us with the legacy of the curly brackets (for which one has to
>> shift press) rather than the square (for which one simply has to
>> press)?
<snip>
> Anyways, this dates back to a long history of programming languages,
> starting with BCPL,
Small detail: BCPL (at least the BCPL compilers I've seen) used $( and $).
> upon which it migrated to B,
Yes, by B it had become { and }
> C,
and then C allowed ??< and ??> and, later, <% and %>!
--
Ben.
Rik Wasmus
<dorayme...@optusnet.com.au> wrote:
> In article <61477$4748b3b4$40cba7aa$70...@NAXS.COM>,
> "Jonathan N. Little" <lws...@centralva.net> wrote:
>
>> dorayme wrote:
>>
>> > [On counting the shift as a keypress: for a start, you absolutely
>> > need a second hand. <g>]
>> >
>>
>> Must be a Mac minimalist-thinking thing, like that one-button mouse! ;-)
>
> Actually, I was wrong, not "absolutely at all". Sorry. There are
> two shift keys and one *can* use the right one and bracket key
> with one hand. But! There is an energy cost and it involves the
> movement of the thumb in an unnatural manner (as if to fold it
> onto the palm of the hand) so that it engages that shift while
> the fore or middle finger does the bracket key. This is RSI
> territory.
That seems quite personal. Years and years ago, in a land far, far away, I
learned I had 10 finger and should use all 10 when typing. This means the
finger located nearest to a button are used. A square bracket for me is
either left-pinky/right pinky or right pinky/ right ringfinger, whichever
is more handy considering the characters typed before and afters. (Ha, it
seems we dutch gave you the word 'pinky'/'pinkie'. Isn't it weird that as
the mmost little one, it's the only non-opposable finger which has it's
own name, instead of 'that kind of' - finger. I'd think the more widely
and intensivly used index finger is far more deserving of a name of its
own....) I don't think I've ever used any finger other than the little
finger to press shift the last years, except for the times I needed a CTRL
key (in which case the ringfinger takes over the shift key).
Hell, I don't think enter has been touched by any other finger then my
right little finger in years, as tab is solely moved by the left pinky...
> I have to say, Jonathan that I find it very awkward to alt C (and
> V) on your keyboard, Command and C (or V) on a Mac are closer
> together.
Hmm, closer together for me usually means more trouble, not less.
--
Rik Wasmus
Harlan Messinger
Yes, resistance is futile!
Steve Swift
> After all, HTML and XML live and die by the shift-loving less-than
> and greater-than characters!
Surely there's a website somewhere to which you could submit a selection
of your source files and it tells you which country you should emigrate
to in order to end up with a keyboard requiring the minimum number of
shift key presses? :-)
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Gregor Kofler
> p [margin: 0;]
>
> is two key presses shorter then
>
> p {margin: 0;}
Not on my keyboard...
Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Stan Brown
<lws...@centralva.net>:
> dorayme wrote:
> > Is there some particular reason that the inventors of CSS chose
> > to leave us with the legacy of the curly brackets (for which one
> > has to shift press) rather than the square (for which one simply
> > has to press)?
>
> feature because of IE.
But it could just as easily have been the other way. Good design
would say to use the shorter keystrokes for the more-commonly-
occurring use.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
Ben C
> Fri, 23 Nov 2007 23:22:20 -0500 from Jonathan N. Little
><lws...@centralva.net>:
>> dorayme wrote:
>> > Is there some particular reason that the inventors of CSS chose
>> > to leave us with the legacy of the curly brackets (for which one
>> > has to shift press) rather than the square (for which one simply
>> > has to press)?
>>
>> Square brackets are for attribute selectors. A useful but not often used
>> feature because of IE.
>
> But it could just as easily have been the other way. Good design
> would say to use the shorter keystrokes for the more-commonly-
> occurring use.
That's good keyboard design, not good syntax design. Syntax should be
designed for clarity and readability, not to be easy to type. If you
don't like typing something then just set up some macros in your editor.
dorayme
Ben C <spam...@spam.eggs> wrote:
> Syntax should be
> designed for clarity and readability, not to be easy to type. If you
> don't like typing something then just set up some macros in your editor.
Hard to argue with this. About the "just" in "just set up some
macros...", reminds me: On a previous Mac OS I had a very handy
macro program (keyQuencer) but it was not native OS X last time I
looked. On the strictly limited task of sq. versus curly, the
simplest fix would be to reverse the function of that one key.
These days, I use the square brackets nowhere near as often (I
use them for GREP expressions a bit and in footnotes to articles)
--
dorayme
Andy Dingley
> Is there some particular reason that the inventors of CSS chose
> to leave us with the legacy of the curly brackets (for which one
> has to shift press) rather than the square (for which one simply
> has to press)?
>
Force of habit in the software world. {...} is a common indicator for
block structure.
One downside of this is to encourage programmers to think of these as
"CSS blocks", whcih are selected or not as a single unit, owing to the
selector cascade rules. In fact CSS works the other way, by applying
each selector in turn to each individual rule within the block. This
is probably the single most common misunderstanding of CSS use amongst
ex-programmers.
Ben C
> On 24 Nov, 04:02, dorayme <doraymeRidT...@optusnet.com.au> wrote:
>> Is there some particular reason that the inventors of CSS chose
>> to leave us with the legacy of the curly brackets (for which one
>> has to shift press) rather than the square (for which one simply
>> has to press)?
>>
>> p [margin: 0;]
>
> Force of habit in the software world. {...} is a common indicator for
> block structure.
>
> One downside of this is to encourage programmers to think of these as
> "CSS blocks", whcih are selected or not as a single unit, owing to the
> selector cascade rules.
It does work like that doesn't it?
Regardless of how browsers are actually implemented, it works to think
of it roughly like this:
for each element
{
for each selector that matches the element, in reverse order of specificity
{
apply all of the properties in the {..}, overwriting any that
were already set.
}
}
(ignoring style attribute).
> In fact CSS works the other way, by applying each selector in turn to
> each individual rule within the block.
Perhaps you're thinking of something like this, which would also work,
but isn't any clearer a way of thinking of it:
for each element
{
1. Get all the selectors that match that element.
2. Distribute each selector through its corresponding {..} giving a
list of (selector, property) pairs.
3. Concatenate all those lists together into one big one.
4. Uniquify that list on properties, keeping the ones with the
most specific selectors.
5. Apply all the properties the element.
}
Wolfgang Draxinger
> Is there some particular reason that the inventors of CSS chose
> to leave us with the legacy of the curly brackets (for which
> one has to shift press) rather than the square (for which one
> simply has to press)?
>
> p [margin: 0;]
>
> is two key presses shorter then
>
> p {margin: 0;}
>
> Multiply that by a few billion over the world of css, taking in
> to account a lot of consequences including the bigger chance of
> typos and revisions, the greater expenditure of energy on
> people and processors, more wear and tear on the keyboard.
>
You got a US centric view of the world. There are other keyboard
layouts than the standard US. And depending on the Layout the
curly braces are shorter to reach than the square brackets.
So what's the big deal? You want to define the elements of a
programming language by a /keyboard layout/? That must be a
joke. I prefer to design programming languages by the way it
looks to me. And in almost all programming languages [...]
denote the index operator, which is definitely something else
than a block structure.
Wolfgang Draxinger
--
E-Mail address works, Jabber: hexa...@jabber.org, ICQ: 134682867
Andy Dingley
> On 2007-11-27, Andy Dingley <ding...@codesmiths.com> wrote:
>
> > On 24 Nov, 04:02, dorayme <doraymeRidT...@optusnet.com.au> wrote:
> >> Is there some particular reason that the inventors of CSS chose
> >> to leave us with the legacy of the curly brackets (for which one
> >> has to shift press) rather than the square (for which one simply
> >> has to press)?
>
> >> p [margin: 0;]
>
> > Force of habit in the software world. {...} is a common indicator for
> > block structure.
>
> > One downside of this is to encourage programmers to think of these as
> > "CSS blocks", whcih are selected or not as a single unit, owing to the
> > selector cascade rules.
>
> It does work like that doesn't it?
No it doesn't. However if the set of declarations within each block is
the same (and in the limiting case, that's simply one per block), then
the results are the same.
The confusion arises when there are blocks containing properties { A,
B, C } and { A, C, D } and some overlap in their selectors. It's
fairly obvious when B & D are affected, but A & C are much more
complex. In particular it's easy to generate examples where A or C
receive different final values from that expected according to the
value specified for for B & D "because it's in the same block". The
whole concept of "because it's in the same block" just isn't relevant
to CSS, but CSS coders do persist in thinking it is.
> for each selector that matches the element, in reverse order of specificity
> {
> apply all of the properties in the {..}, overwriting any that
> were already set.
> }
Definitely not!
> > In fact CSS works the other way, by applying each selector in turn to
> > each individual rule within the block.
>
> Perhaps you're thinking of something like this, which would also work,
> but isn't any clearer a way of thinking of it:
It certainly isn't "clearer". But if you permit the rules to allow
blocks of varying cardinality, then that's how you have to implement
it. Anything else would end up with non-deterministic rules to select
whether blocks of mixed cardinality ought to be applied or not.
> for each element
> {
> 1. Get all the selectors that match that element.
> 2. Distribute each selector through its corresponding {..} giving a
> list of (selector, property) pairs.
> 3. Concatenate all those lists together into one big one.
> 4. Uniquify that list on properties, keeping the ones with the
> most specific selectors.
> 5. Apply all the properties the element.
That's pretty much it.
Ben C
> On 27 Nov, 11:13, Ben C <spams...@spam.eggs> wrote:
>> On 2007-11-27, Andy Dingley <ding...@codesmiths.com> wrote:
>> > One downside of this is to encourage programmers to think of these as
>> > "CSS blocks", whcih are selected or not as a single unit, owing to the
>> > selector cascade rules.
>>
>> It does work like that doesn't it?
>
> No it doesn't. However if the set of declarations within each block is
> the same (and in the limiting case, that's simply one per block), then
> the results are the same.
>
> The confusion arises when there are blocks containing properties { A,
> B, C } and { A, C, D } and some overlap in their selectors. It's
> fairly obvious when B & D are affected, but A & C are much more
> complex. In particular it's easy to generate examples where A or C
> receive different final values from that expected according to the
> value specified for for B & D "because it's in the same block". The
> whole concept of "because it's in the same block" just isn't relevant
> to CSS, but CSS coders do persist in thinking it is.
>
>> for each selector that matches the element, in reverse order of specificity
>> {
>> apply all of the properties in the {..}, overwriting any that
>> were already set.
>> }
>
> Definitely not!
I don't understand. The two "pseudocode" implementations I've provided
are equivalent, or that's what I thought. But you seem to be saying the
second one works OK but the first one doesn't.
Here is an example:
<style type="text/css">
.foo
{
background-color: palegreen; /* A */
float: left; /* C */
padding: 100px; /* D */
}
/* This selector is more specific */
div.foo
{
background-color: pink; /* A */
border: 2px solid red; /* B */
float: right; /* C */
text-transform: uppercase; /* E */
}
</style>
...
<div class="foo">
Hello
</div>
The div should have a pink background color, 100px padding, be floated
right, and uppercased. In other words, it gets D from the first block,
and A, C and E from the second.
This can be implemented as described above like this:
The first selector is more specific, so the div gets all the properties
in the block: background palegreen, float left and the padding.
Then the next selector is applied on top: it overwrites background and
float, the padding stays how it was, and the border and text-transform
get added.
I've added text-transform: uppercase to make the blocks have differing
cardinality because that doesn't create any additional problems.
>> > In fact CSS works the other way, by applying each selector in turn to
>> > each individual rule within the block.
>>
>> Perhaps you're thinking of something like this, which would also work,
>> but isn't any clearer a way of thinking of it:
>
> It certainly isn't "clearer". But if you permit the rules to allow
> blocks of varying cardinality, then that's how you have to implement
> it. Anything else would end up with non-deterministic rules to select
> whether blocks of mixed cardinality ought to be applied or not.
I think one of us has misunderstood something. Can you provide an
example where the pseudocode above would give a different result from
the version below?
Sander Tekelenburg
<doraymeRidThis-F15...@news-vip.optusnet.com.au>,
dorayme <dorayme...@optusnet.com.au> wrote:
> In article <user-1DA0ED.0...@textnews.euro.net>,
> Sander Tekelenburg <us...@domain.invalid> wrote:
[...]
> > Perhaps on some keyboards
> > square brackets actually are harder to type.
>
> Well, that is a question, I might be seeing a biassed sample here
> in Australia?
Someone else happened to just point me to a web page that shows some
keyboad lay-outs:
<http://docs.info.apple.com/article.html?artnum=304933>. Thought you
might be interested.
dorayme
Sander Tekelenburg <us...@domain.invalid> wrote:
> In article
> <doraymeRidThis-F15...@news-vip.optusnet.com.au>,
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > In article <user-1DA0ED.0...@textnews.euro.net>,
> > Sander Tekelenburg <us...@domain.invalid> wrote:
>
> [...]
>
> > > Perhaps on some keyboards
> > > square brackets actually are harder to type.
> >
> > Well, that is a question, I might be seeing a biassed sample here
> > in Australia?
>
> Someone else happened to just point me to a web page that shows some
> keyboad lay-outs:
> <http://docs.info.apple.com/article.html?artnum=304933>. Thought you
> might be interested.
Thanks Sander.
(Have Germans got something against curly brackets? Could not see
any on their layout?)
--
dorayme
Johannes Koch
> (Have Germans got something against curly brackets? Could not see
> any on their layout?)
As I wrote earlier in this thread, my german (added: non-Mac) keyboard
has a '{' on AltGr + 7.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
Jukka K. Korpela
> dorayme schrieb:
>> (Have Germans got something against curly brackets? Could not see
>> any on their layout?)
>
> As I wrote earlier in this thread, my german (added: non-Mac) keyboard
> has a '{' on AltGr + 7.
Such assignments are common in "national" (read: non-English) keyboards,
because curly braces belonged to the "national use are" of ISO 646 and
were therefore often replaced by letters in different "national variants
of ASCII" and o keyboards designed to match such codes. This means that
the code and the key for '{', for example, was taken into use for
writing a letter like 'ä' or 'æ' or 'é' or 'à' (or maybe something
else, like '°', or used as dead key for '?'), as explained at
http://www.cs.tut.fi/~jkorpela/chars.html#national-ascii
It was funny time. Of course we didn't write CSS at that time, but we
used C, for example, and the C language makes heavy use of curly braces.
So we had to live with things like
if(!n) ä ... å
instead of
if(!n) { ... }
since the same terminals were used both for text processing and
programming.
Later, when the eighth bit had been invented :-) and ISO-8859-1 came
into use, we were able to afford both 'ä' (for example) and '{' on the
same keyboard. But 'ä', being an important letter (e.g., the 11th in
frequency order in Finnish), was kept in its "traditional" position, and
the technical, nerdish special character '{' was put to whatever
position was found suitable at that time.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
Andreas Prilop
> User-Agent: MT-NewsWatcher/3.5.1 (Intel Mac OS X)
>
> (Have Germans got something against curly brackets? Could not see
> any on their layout?)
Apple Bavaria ignores the German standard DIN 2137 for keyboard
layouts. On standard German keyboards, you find { } on 7 9
and [ ] on 8 9 .
--
¹ superscript 1 ¼ fraction 1/4 Ð D stroke ð d stroke
² superscript 2 ½ fraction 1/2 Þ Thorn þ thorn
³ superscript 3 ¾ fraction 3/4 Ý Y acute ý y acute
× multiply sign ¦ broken bar
Andreas Prilop
> Apple Bavaria ignores the German standard DIN 2137 for keyboard
> layouts. On standard German keyboards, you find { } on 7 9
> and [ ] on 8 9 .
Sorry - typo. I meant { } on 7 0 .
7 8 9 0
{ [ ] }
--
Bugs in Internet Explorer 7
http://www.unics.uni-hannover.de/nhtcapri/ie7-bugs