Please note that CSS Variables are not like SASS/LESS variables. They're actually <i>custom properties</i> that obey inheritance.<p>They're scoped to document rather than stylesheet, so you can override them in parts of the document just like you can override any CSS property.<p>Example from the spec:<p><pre><code> :root { var-color: blue; }
div { var-color: green; }
#alert { var-color: red; }
* { color: var(color); }
<p>I inherited blue from the root element!</p>
<div>I got green set directly on me!</div>
<div id='alert'>
While I got red set directly on me!
<p>I’m red too, because of inheritance!</p>
</div></code></pre>
W3C strikes again. They are uniquely gifted at creating ungainly and ugly standards even in the face of widespread industry practices are already commonly used (less, sass). I really want to know who thought `var-` prefix was a banging idea.
CSS variables are the only reason I started using Sass and LESS in the first place. But although these preprocessors come with other interesting features, I never managed to truly incorporate them in my workflow.<p>The way I ended up solving the CSS variables issue (i.e. replacing the same property/value combination in multiple locations) was to actually regroup <i>selectors</i>.<p>For example, I'd have:<p><pre><code> #title,
.nav a,
.post-title em {
color: #db4e44;
}
</code></pre>
The only annoying thing is that it can result in a long list of selectors (although I'd put them on one line anyway). But one thing I truly appreciate with this approach is that you can edit <i>any</i> value with your browser's inspector, and see it <i>instantly</i> update all instances at once. It's great to test out new colors for example.<p>The other option would be to have a specific class that would apply this style. But then, you'd move the styling from the CSS to the HTML, and I've always tried to prevent myself from breaking this golden rule.
Does anyone know if there's a polyfill for CSS variables out there? Possibly a library that creates plain old CSS out of the one that uses variables. It would be useful until this is rolled out to other browsers.
I like that you can overwrite the var(headersize) in a different style. That makes these pretty powerful. However, var(headersize) is a lot to type, compared to @headersize (like LESS) or $headersize (like SASS). CSS allows for a lot of shorthand (#AABBCC = #AAA, table tr td a ~= table td a, * {}). Would be nice if there was a shorthand for variables too since they'll be used so much.
The downside of this (unless I'm missing something) is that these variables need to be evaluated on the client side and inevitably slow down CSS processing (at least for the first time that is). I really like the fact that you can preprocess both LESS and Sass (and others) to just plain CSS and hide all of the dynamic behavior (far more then just variables).
By the way, [AbsurdJS][1] is an interesting alternative to Sass/LESS. It lets you write your CSS in JavaScript (and have it compiled to CSS). Thus, you get mixins, variables and plugins without some DSL to learn/use/depend on—all written in JavaScript.<p><pre><code> [1]: http://krasimir.github.io/absurd/</code></pre>
Wow CSS is becoming more and more like a programming language. Good job on Firefox for pushing the boundary.<p>One thing though. The calculations don't seem very semantic. To calculate something as simple as height/width, you need a long calc(var(height)/var(width));<p>Maybe w3 can implement CSS variables with special characters like in PHP.
I just can't see what the path to adoption of this looks like. How do you achieve backward compatibility?<p>You put a box-shadow on your elements today and while it won't look quite as shiny in browsers that don't support it, it's not going to affect usability. If you put a variable in that stylesheet, say to make the background of all your clickable elements blue, how do you provide a fallback for the browsers that don't understand the directive? If my elements aren't blue in anything except the latest build of FF, there's no way I can justify using the feature, obviously (as much as I like the idea of it).
It would be great if there was a new standard like LESS/SASS for on the fly browser CSS creation. Think of the download speed up and the simplicity, removing minifiers, bandwidth, complexity. Also when new browser support elements are added the intermediary layer will just be the global one always even during development. Browsers will just add them to this instead of prefixed properties moz- etc. Support can change with the same simple stylesheets, browsers worry about it.
I'm not sure why, but reading this news is not so exciting. SASS/LESS are basically a standard ( along with Compass and other ), so I'm not sure how CSSWG will get out of the mess they made with "-moz,-webkit,-o" and many, many others ... Native support of CSS variables is like querySelectorAll. You got it, but you still use jQuery, because of backward / forward support.
Nifty. I'm really looking forward to using those in several years.<p>The need for CSS variables has only been apparent for about forever. What took so long?
I don't like this.<p>I prefer the freedom of platforms like LESS or SASS. They can implement changes faster and they can have full set of features without worrying about updates or platforms. They just output standard CSS.<p>If we relay on browser features, we will be slower, we will tie up to vendor differences and things will get complicate over time to develop something cool, in fact, there will be projects for sure that re-unify what browsers precompile, so, no to this.<p>I would suggest vendors to support the standard CSS spec to the max, and keep this good work instead going something really new like this.