CSS variables
Weeee, CSS variables just landed in WebKit, this is pretty exciting!
Unfortunately I couldn't see them in action in WebKit nightly (must be something I'm missing), but they're here and here to stay. I know there are "purists" that say that stuff like variables has no place in the language and we don't really understand CSS, it's different, etc, etc. But once W3C has a modest proposal and one major engine is implementing variables, then this is where we're headed. And I personally applaud this direction.
Syntax
So the basic idea, according to W3C is this. There are two steps: you declare a variable (together with a value assignment) and then you use it.
This is a declaration of the variable my-color. It's a global variable (defined under :root).
:root { var-my-color: #fad; }
Then you use it like:
.thing { color: var(my-color); }
And the .thing gets the color #fad.
In WebKit
Webkit currently uses a -webkit vendor prefix which makes the whole thing more verbose:
:root { -webkit-var-my-color: #fad; } .thing { color: -webkit-var(my-color); }
There are many examples for your browsing pleasure in the form of test files in WebKit's repo
Future
It's here. And it's only getting better. There's a dev draft of the CSS variables proposal which talks about using $ instead of var() to refer to a variable, which is so much nicer. Spoken like a true php'ied, eh? 
:root { var-my-color: #fad; } .thing { color: $my-color; }
Exciting times!
This entry was posted on Thursday, June 14th, 2012 and is filed under CSS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Get notification for future posts: follow me on Twitter or subscribe to my RSS feed
June 14th, 2012 at 3:59 am
Exciting times in WebKit-land!
The vendor prefix does make it a bit less useful for now, but at least we are getting there. The future spec looks promising, but I’m still not comfortable with the syntax, especially the declaration syntax. Why not do it the SASS way and get/set your variables with the same syntax? With the current syntax I would force myself to camelCase to make it more readable ex. var-my-awesome-variable is much less readable than var-myAwesomeVariable.
Great post, Stoyan!
June 14th, 2012 at 4:04 am
without the rest of the features, currently available only as part of preprocessors, e.g. sass/compass, those variables are missing half of the power
June 14th, 2012 at 10:23 am
I agree with Martin. Preprocessor are bring more to the table than simply variables. Can’t wait to see more.
I don’t see preprocessors going away honestly. The “Backwards compatibility” problem is going to force you to have to include old, verbose, non-variable CSS along with the variable support. Why do this manually, when you can just use a CSS preprocessor?
June 14th, 2012 at 4:21 pm
Zoomph, to me CSS vars are a case *for* using some sort of preprocessor and a case *against* the naysayers. A CSS purist well-versed in following web standards to the letter and using XHTML doctype will be more willing to use a standard-defined feature and live with a preprocessor that translates it to older browsers. Otherwise before W3C defines CSS vars, they are just non-standard (therefore questionable) abomination and evil
June 14th, 2012 at 5:48 pm
@Kristof using a different way to define the variables would break the parsers in old browsers. The method defined in the standard means they just ignore the declaration because they just think it is an unsupported property.
June 15th, 2012 at 5:42 pm
[...] them off. It will be a long while until we can use them in production but hey, onward and upward!Direct Link to Article — Permalink…First Sighting: CSS Variables is a post from CSS-TricksOriginally posted [...]
June 15th, 2012 at 5:43 pm
This is a great CSS news! If it will be rest simple as it seems it could be very useful! Thank you Stoyan!
June 15th, 2012 at 6:19 pm
Weren’t CSS variables proposed before with a simpler syntax?
@mycolor: #fad;.thing {
color: @mycolor;
}
The whole :root {} and var- stuff isn’t my cup of tea. Even if they’re trying to make this not break browser behavior, the var- prefix for variables seems messy to me and not very CSS-like.
Anyway, the LESS preprocessor currently implements the simpler variables syntax which I like so I guess I’ll keep using that. It is nice that native variables are coming to CSS though.
June 15th, 2012 at 6:30 pm
[...] Direct Link to Article — Permalink… [...]
June 15th, 2012 at 6:32 pm
I’d rather see Webkit being fixed to work with standard syntax instead of trying to add even more non-standard (anything that uses a vendor prefix) bells and whistles. Anyone who wants CSS variables can use one of the many pre-processors that handle that. And that’s where variables and functions belong – in the pre-processor, not in client side CSS.
June 15th, 2012 at 8:01 pm
And the part that ruins it is the vendor prefix, great… great…. now, for something that’s supposed to save time and ease developing, they’ve made it harder and more complicated… this vendor prefix shit is getting really old..
June 15th, 2012 at 10:18 pm
I can already imagine all the things you can do with this in javascript
June 16th, 2012 at 12:06 am
[...] Direct Link to Article — Permalink [...]
June 16th, 2012 at 1:04 am
simply gud
June 16th, 2012 at 1:36 am
[...] Direct Link to Article — Permalink [...]
June 16th, 2012 at 1:57 am
Interesting. Unfortunately this kind of vars can´t change dynamically like in PHP. So there is much lesser use. Right now I combine php and css in the style sheet (as style.php instead of style.css) to do pretty much the same – and dynamically.
June 16th, 2012 at 3:22 am
This is huge, I think in the right direction
June 16th, 2012 at 8:02 am
[...] CSS variables - Weeee, CSS variables just landed in WebKit, this is pretty exciting! I know there are “purists” that say that stuff like variables has no place in the language and we don’t really understand CSS, it’s different, etc, etc. [...]
June 16th, 2012 at 12:30 pm
Thanks for that. It’s great to see variables getting rolled out in CSS.
But, why not prefix the variable declaration with $ as well? Is there a reason for not doing that? Surely it would be neater. Eg:
:root {
$my-color: #fad ;
}
Then:
#div {
color: $my-color;
}
I like the way the variable can be scoped to a particular DOM sub-tree tho. Nice.
June 16th, 2012 at 5:35 pm
It’s very interesting in my opinion. If we get CSS true variables and can even pass them off to web languages, imagine the slick stuff we could do with it.
On the other hand, it’s going to complicate the language at least a little (and CSS has always been great because it is user-friendly). It won’t bother me, but I’m sure there are those who will have some trouble at first.
June 16th, 2012 at 9:43 pm
I’ll stick to sass for now, but this is great news for the future!
June 18th, 2012 at 1:40 am
nice,
waiting for it
June 18th, 2012 at 5:37 am
[...] Via [...]
June 18th, 2012 at 6:22 am
Hey,
I think this functionality is not variables but constants!
“there are “purists” that say that stuff like variables has no place in the language” I might agree with that point of view. Bacause in CSS there is no run! CSS is just static decalrations and we want use “variables” bacause we want declare favourite colour just once and use name for it – changing the value is simpler, just in one place – in declaration. So this is not variable bacause in the run of scirpt (?) stylesheet value doesn’t change -This is the Constant
June 18th, 2012 at 1:50 pm
I applaud this too.
Was under impression that standardization organizations had “purist” views on keeping web standards at level of “non developers”. ECMA4 was screwed and did read a lengthy article from standardization guys before on “why CSS does not need variables”… Very sad…
But it seems competing initiatives like Dart, SASS/LESS, CoffeScript and others by becoming popular among developers will make standards standup from stagnation.
June 19th, 2012 at 7:03 pm
Would love to play with this is Webkit Nightly …
June 20th, 2012 at 8:51 am
Why introducing variables into CSS? It’s a simple language, why not just keeping it this way? I don’t feel this is good at all, calculations, variables, mixin … seems to me like CSS is turning into a beast.
June 20th, 2012 at 1:50 pm
This is good, all the preprocessors are the same anyways, YAY for standardization.
June 20th, 2012 at 5:10 pm
I think I’d want to do it like this:
:root {
$something:#aabbcc;
}
.thing {
color:$something;
}
June 24th, 2012 at 8:03 am
Nice to see, so less/sass will become redundant?
Greetz
Ron
July 2nd, 2012 at 7:36 am
@synlag That’s the plan!
July 3rd, 2012 at 5:22 pm
#content { color: red; $xxx: red; color: $xxx; border: 2px dashed blue; }
this is backwards compatible (tested on this page, parser just skips unknown rules), and much more readable/writable than current syntax.
seems like @cnwtx, @Michael Mason and @Sunny Singh have all came to the same natural syntax. Accident ? Hardly.
August 21st, 2012 at 6:57 am
This is a great CSS news!
October 31st, 2012 at 9:07 pm
Just wanted to say i am enjoying the program. i am in Dakar Senegal west africa