CSS Variables published as First Public Working Draft
lists.w3.org
lists.w3.org
:root {
var-header-color: #06c;
}
h1 {
background-color: var(header-color);
}
Compare that to Less: @header-color: #06c;
h1 {
background-color: @header-color;
}
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 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.
$header-color: #06c;
h1 {
background-color: $header-color;
} :vars {
header-color: #06c;
header-font: helvetica;
}
h1 {
font-family: $header-font;
background-color: $header-color;
}:root { var-color: #000; }
p { var-color: #666; }
* { color: var(color) }
"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."
Neat feature. Probably won't be relevant by the time it's approved.
I really don't get why MS don't fork their browser into corporate and consumer versions. Let the corporate users run on ie6/7 or whatever legacy crap they need and let the rest of the web move at a reasonable pace.
Anyway that's where I think the hostility to IE is coming from.
Now all that being said, if IE really has gotten it's act together as you say then I'd be happy to call it a day. Unfortunately no matter how wonderful it is, it probably won't matter until IE8 and IE9 virtually dead (<7.5% of sessions for a site).
Edit: Release schedule of Internet Explorer... IE7: 2006, IE8: 2009, IE9: 2011, IE10: 2011 (announced "3 weeks in development")
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.
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'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.
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.
This lack of variables in CSS is already being solved in a nonstandard way. Might as well standardise a solution.
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); }.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?
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.
.selector1, .selector2 { color: green }
.selector3, .selector4 { color: red }
.selector1, .selector3 { width: 100px }
.selector2, .selector4 { width: 200px }
No variables, no multiple classes. Now, I'm not saying that this is better than variables, or that variables won't make it easier to manage. But you don't have to repeat attributes or use many classes for each element currently in CSS, you just have to organize it a bit differently than you might expect at first.I need an editor/IDE with a dropdown that displays the properties of any element in one panel, perhaps showing me where the actual stylesheet changes are made in a side column. Like editing styles in Firebug, only smarter. Anyone got a recommendation?
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.
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.