W3C Hammers Out the Details of CSS Variables

W3C Hammers Out the Details of CSS Variables:

The mythical Jackalope variable surrounded by CSS bunnies. Image: Wikimedia

The W3C’s CSS Working Group, the standards body that oversees the CSS specification, is getting closer to defining one of CSS’s most requested features — CSS Variables. However, if you’ve been dreaming of SASS or LESS style power without the preprocessor, the new CSS Variables draft might leave you scratching your head.

Variables used to be one of the most requested features for CSS, particularly from programmers accustomed to languages with variables. But, between then and now, CSS preprocessors like SASS and LESS have largely filled the role by offering variables (and more). Still, SASS and LESS are not CSS.
By the same token, what’s being proposed under the name CSS Variables is not what most developers would think of as a variable. Daniel Glazman, co-chair of the W3C CSS Working Group, calls the new variables “Inherited User-Defined Properties.”

In fact what is being proposed are custom properties which use a function to access the value of the properties later — more of a Mutator getter/setter pair than a directly accessible variable.
When variables were first proposed many assumed the syntax would look something like SASS or LESS, roughly like this:

$foo = myvalue;

/* and then */
.selector {
    color: $foo;
}

We showcased the actual syntax back when WebKit first landed preliminary support for variables, but here’s a quick refresher:

:root {
    var-header-color: #06c;
}
h1 { background-color: var(header-color); }

The first rule is the new variable syntax and defines a property named “var-header-color” on the root element. Then you can then access that value throughout your stylesheets with the var(header-color) syntax.
Why not use the more familiar PHP-like “$var” syntax? For one thing this proposal makes it easier to understand the cascade. See Glazman’s blog for more details on how variables will inherit. Tab Atkins Jr, a Google representative at the CSS Working Group, explains another reason to switch to the new syntax: “If we use $foo for variables, we’ll be unable to use it for future ‘variable-like’ things.”
So what are “variable-like” things? Atkins continues:

For example, if we do define an alternate form that are more SASS-like (can be used anywhere, but are global; more “macros” than “variables”) we’d have to use some other glyph for them. That’s suboptimal. More specifically, if we ever do some sort of “variables” in selectors, we must use a compact form like $foo or something. Anything else is unusable, I believe.

So we have our variables in CSS, but with a syntax that’s not quite the way many developers wanted it. As Glazman writes, “Before shouting, don’t misunderstand us: we clearly see the simplicity, readability and maintainability of the $foo syntax… we do understand why Web Authors prefer a compact and simple notation like $foo but we have decided it comes at a too expensive cost right now.”

If you’re really put off by the new syntax, take comfort in the fact that the variables draft remains just that — a draft spec. Glazman and Atkins both leave the door open to adding $foo style variables back to the spec. As Atkins writes, “If we don’t find anything that needs this kind of syntax, then we can go back to letting Variables consume this kind of syntax for its own use.”