CSS variables

June 14th, 2012. Tagged: CSS

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!

Tell your friends about this post: Facebook, Twitter, Google+

34 Responses

  1. 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!

  2. 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 :)

  3. 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?

  4. 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 :)

  5. Anthony Richardson

    @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.

  6. [...] 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 [...]

  7. This is a great CSS news! If it will be rest simple as it seems it could be very useful! Thank you Stoyan!

  8. 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.

  9. [...] Direct Link to Article — Permalink… [...]

  10. 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.

  11. 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..

  12. I can already imagine all the things you can do with this in javascript

  13. [...] Direct Link to Article — Permalink [...]

  14. simply gud

  15. [...] Direct Link to Article — Permalink [...]

  16. 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.

  17. This is huge, I think in the right direction

  18. [...] 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. [...]

  19. 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.

  20. 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.

  21. I’ll stick to sass for now, but this is great news for the future!

  22. nice,
    waiting for it

  23. [...] Via [...]

  24. 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 :)

  25. 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.

  26. Would love to play with this is Webkit Nightly …

  27. 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.

  28. This is good, all the preprocessors are the same anyways, YAY for standardization.

  29. I think I’d want to do it like this:

    :root {
    $something:#aabbcc;
    }

    .thing {
    color:$something;
    }

  30. Nice to see, so less/sass will become redundant?

    Greetz
    Ron

  31. @synlag That’s the plan!

  32. #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.

  33. This is a great CSS news!

  34. Just wanted to say i am enjoying the program. i am in Dakar Senegal west africa

Leave a Reply