I can understand why they opted out of the @-notation in favor of something a bit more in line with existing CSS, but it just looks overly complicated to me.
"As defined here, the syntax for variable usage is different from the syntax for variable definition (i.e. var-foo for definition, var(foo) for usage). Some have suggested that the syntaxes should should match, using functional syntax in both cases. Others have suggested using a prefixed symbol instead of functional syntax (e.g. $foo) for both the property and usage."
As I understand it, at-rules are basically directives to the CSS parser and, according to the spec, should be ignored if the parser does not recognize the identifier. Given that, the use of at-rules for variable names has always seemed, IMVHO, to break the purpose of at-rules.
The issue wouldn't be implementation, that usually happens pretty quickly nowadays. The wait for older versions of browsers to become irrelevant, however, will probably be a long one.
I'm probably a tiny minority but I don't like that CSS is becoming so bloated with features that overlap fully-fledged programming languages. Yes, it's becoming more powerful but I wonder if some of this is due to an inherent "right, what can we add next?" attitude which takes it further away from its presentational role.
I also mourn the loss of a simplicity that meant that curious teenagers (like myself way back when) could look at a site's code and easily learn from it.
Well, I'm a curious teenager. Personally, I think source is somewhat easier to understand on modern sites.
The use of CSS and divs instead of tables for layouts has had an interesting side effect: most elements of a page have IDs or classes. This makes it far more obvious what they are there for without having to use a web page inspector.
That said, the continuing expansion of HTML, CSS and JavaScript APIs worries me too, but for a different reason. I'm worried that the stack will become so big that there is no possibility of new rendering engines or browsers.
I agree with your "what can we add next" qualm, but I'm not feeling that way about variables in CSS. I don't see variables hindering code readability/learnability. As a front-end guy have you ever exclaimed, "Man, I'm glad CSS doesn't have variables!"?
I've done front-end stuff on and off for a few years and I've always thought variables would be the "easiest" thing for implementers to enhance CSS.
The key difference here being that rather than looking at whatever bloat they can add this time, CSS variables are actually derived from an acute need in the community. So much, that there are even two CSS preprocessors/frameworks that already add this (SASS and Less).
This lack of variables in CSS is already being solved in a nonstandard way. Might as well standardise a solution.
CSS variables don't impact CSS' simplicity. If you need CSS to be simple, its still gonna have that, but when you get around to needing:
css variables, transforms, gradients, border-radius, multiple background images, etc.
... you'll be glad to know that those features are available as well and that you don't have to add complexity to whatever you're building to hack those in. I also don't see how CSS variables, or other recent CSS features, hinder anyone from learning from a site's code.
All these things make it easier to create stuff. My only complaint is that they're not added soon enough.
For those asking why, color replacement is enough to have them implemented. Once your stylesheet grows, you'll have your theme colors scattered all over the place. So having them in one place at the top and making minor changes to the theme is a great time saving feature.
The spec allows the same variable to be defined multiple times, and have cascading determine which value is used.
As far as I can see this completely removes the ability to implement variables in a preprocessor (i.e. serve a style sheet with variables substituted with their values to Internet Explorer). So developers can't use the feature until it's made available on all browsers.
Consider the following code. It can't be translated back into standard CSS without knowing the DOM structure of the document it will be applied to.
#nav { var-color: red; }
#side { var-color: blue; }
body p { color: var(color); }
I don't understand the use of something like this. Instead of:
.selector-1{a:b;color:red;}
...hundreds of other things...
.selector-2{c:d;color:red;}
someone can just:
.selector-1, .selector-2{color:red;}
...hundreds of other things...
It seems to me most cases where variables are used they are needed because of writing bad css in the first place. Use a colour only once and you only need to change it in 1 place, why do you need a variable for that?
You seem to go about CSS very differently then most. The typical way of doing styleshets is more or less "What properties does this type of element have? Now what about this type?..." Rather than "Now which elements on my site have this property-value? What about this property-value?..."
Which isn't to say that comma syntax is in any way rare, just that CSS is usually approached by pairing properties to selectors, not the other way around. I would say this helps your style sheet make intuitive sense too. If you want to change the color of the sidebar text, you find the part of your style sheet for #sidebar and then change the color property, rather than finding the section for "blue", removing the sidebar from a big comma separated list of selectors, then placing it into a similar list for "green".
From this standpoint variables make a lot of sense.
But then when quarter of your red things have one width, and that's the same width as quarter of your green things, and another quarter of the reds have another width, which is the same as quarter of your orange things ... then you need variables again or you end up using multiple classes for each object just so that you can apply multiple properties.
First, I think it is inappropriate to down vote this comment as it is a valid point that you can actually solve the color problem in current CSS.
However, building your CSS in this way probably takes a lot longer to render since the selectors are expensive and setting attributes is cheap. Further, I have never seen a page of any complexity where this would make sense.
Maybe this is a bad practice, but I've just been using PHP inside CSS for quite a while. You may need to tweak your .htaccess to allow PHP in .css files, assuming you're on Apache.
p {color: <?php echo $mainColor; ?>}
I did some basic testing and it didn't seem to hurt resource usage, but it wasn't a large site or anything.
[+] [-] micheljansen|14 years ago|reply
[+] [-] Kilimanjaro|14 years ago|reply
[+] [-] wdewind|14 years ago|reply
"As defined here, the syntax for variable usage is different from the syntax for variable definition (i.e. var-foo for definition, var(foo) for usage). Some have suggested that the syntaxes should should match, using functional syntax in both cases. Others have suggested using a prefixed symbol instead of functional syntax (e.g. $foo) for both the property and usage."
[+] [-] carbon8|14 years ago|reply
As I understand it, at-rules are basically directives to the CSS parser and, according to the spec, should be ignored if the parser does not recognize the identifier. Given that, the use of at-rules for variable names has always seemed, IMVHO, to break the purpose of at-rules.
[+] [-] nthitz|14 years ago|reply
[+] [-] JoshTriplett|14 years ago|reply
[+] [-] InclinedPlane|14 years ago|reply
[+] [-] cheald|14 years ago|reply
Neat feature. Probably won't be relevant by the time it's approved.
[+] [-] Zirro|14 years ago|reply
[+] [-] evoxed|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] tagawa|14 years ago|reply
I also mourn the loss of a simplicity that meant that curious teenagers (like myself way back when) could look at a site's code and easily learn from it.
[+] [-] TazeTSchnitzel|14 years ago|reply
The use of CSS and divs instead of tables for layouts has had an interesting side effect: most elements of a page have IDs or classes. This makes it far more obvious what they are there for without having to use a web page inspector.
That said, the continuing expansion of HTML, CSS and JavaScript APIs worries me too, but for a different reason. I'm worried that the stack will become so big that there is no possibility of new rendering engines or browsers.
[+] [-] lbotos|14 years ago|reply
I've done front-end stuff on and off for a few years and I've always thought variables would be the "easiest" thing for implementers to enhance CSS.
[+] [-] micheljansen|14 years ago|reply
This lack of variables in CSS is already being solved in a nonstandard way. Might as well standardise a solution.
[+] [-] mzarate06|14 years ago|reply
css variables, transforms, gradients, border-radius, multiple background images, etc.
... you'll be glad to know that those features are available as well and that you don't have to add complexity to whatever you're building to hack those in. I also don't see how CSS variables, or other recent CSS features, hinder anyone from learning from a site's code.
All these things make it easier to create stuff. My only complaint is that they're not added soon enough.
[+] [-] mrigor|14 years ago|reply
[+] [-] gavinlynch|14 years ago|reply
http://www.w3.org/TR/2012/WD-css-variables-20120410/
[+] [-] Kilimanjaro|14 years ago|reply
[+] [-] underwater|14 years ago|reply
As far as I can see this completely removes the ability to implement variables in a preprocessor (i.e. serve a style sheet with variables substituted with their values to Internet Explorer). So developers can't use the feature until it's made available on all browsers.
Consider the following code. It can't be translated back into standard CSS without knowing the DOM structure of the document it will be applied to.
[+] [-] etherealG|14 years ago|reply
.selector-1{a:b;color:red;} ...hundreds of other things... .selector-2{c:d;color:red;}
someone can just:
.selector-1, .selector-2{color:red;} ...hundreds of other things...
It seems to me most cases where variables are used they are needed because of writing bad css in the first place. Use a colour only once and you only need to change it in 1 place, why do you need a variable for that?
[+] [-] powrtoch|14 years ago|reply
Which isn't to say that comma syntax is in any way rare, just that CSS is usually approached by pairing properties to selectors, not the other way around. I would say this helps your style sheet make intuitive sense too. If you want to change the color of the sidebar text, you find the part of your style sheet for #sidebar and then change the color property, rather than finding the section for "blue", removing the sidebar from a big comma separated list of selectors, then placing it into a similar list for "green".
From this standpoint variables make a lot of sense.
[+] [-] catshirt|14 years ago|reply
[+] [-] pbhjpbhj|14 years ago|reply
[+] [-] spullara|14 years ago|reply
However, building your CSS in this way probably takes a lot longer to render since the selectors are expensive and setting attributes is cheap. Further, I have never seen a page of any complexity where this would make sense.
[+] [-] SquareWheel|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] wtn|14 years ago|reply