HTML5 Zone is brought to you in partnership with:

I'm a Worldwide Developer Evangelist for Adobe. My job basically entails me traveling the world and talking about the developer tools and technologies that Adobe has to offer or that we support. I'm also the author of Driving Technical Change. It's about convinving reluctant co-workers to adopt new tools and techniques. Terrence is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile

Some Problems with the CSS Variables Draft

03.21.2012
| 2419 views |
  • submit to reddit

Thanks to Molly Holzschlag's tweet, I learned there was an Editor's Draft of CSS Variables.

Let me first say that I think it's awesome that the W3C is taking this on. I think that variables in CSS will ultimately be a good thing.  It will make it easy to reuse colors and other CSS properties.  It will make large amounts of redundancy go away.  It will make CSS files smaller, and therefore give less toe-holds to bugs.

That being said I have a major complaint with the implementation--in a word "data."

See, here is how CSS variables are supposed to work according to the draft.

I create a property in the root named "data-header-color."

:root {
  data-header-color: #06c;
}

Then to refer to that color elsewhere, I use a construct that looks like a function named "data()" to retrieve it as so:

h1 { background-color: data(header-color); }

As far as I can tell, the only explanation in the draft for why this is, is that it is trying to match the HTML specification for "data":

The naming here is loosely based on the form of custom data attributes in HTML5. However, as defined here, the syntax for variable usage is different from the syntax for variable definition (i.e. data-foo for definition, data(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.


Well at least they are aware that some might object to this format.  So let me add my voice.  I object. Variables are a pretty standard construct, people know how they work. Make them work like variables in other languages.  I have a bunch of reasons here:

  • Two different syntaxes for creation and consumption seems confusing
  • It looks like you're calling a function, but you're not.  You're referring to a variable.  That's confusing.
  • CSS and HTML don't have a lot of overlap in syntax, why is adding some a good thing?

My preference here is that I can just use plain old words as a variable, then consume them as plain old words. That being said I would be okay with a prefixed symbol, like a $ if it comes down to some sort of parsing issue.

That's my major problem with the draft, but I have one other issue with the behavior on invalid variables. Like if you set the margin to #FFFFFF. Basically if you have this code:

p { background-color: red; }
p { background-color: "Behold I am not a valid color at ALL!!!!" }

Then the p comes out as red, but if you have this code:

:root { data-not-a-color: "Behold I am not a valid color at ALL!!!!" }
p { background-color: red; }
p { background-color: data(not-a-color); }

The p comes out transparent.

This sort of change in behavior might be pretty confusing. The explanation makes some sense:

The invalid at computed-value time concept exists because variables can't "fail early" like other syntax errors can, so by the time the user agent realizes a property value is invalid, it's already thrown away the other cascaded values. I think "attr()" needs to rely on it as well, as its behavior is almost identical to variables.

But I imagine this is something that browser manufacturers can handle as they control the behavior of "throw[ing] away the other cascaded values." They could hold on to cascaded values until they are done computing variables.  But maybe I'm missing something here. But it's also worth considering if this will make invalid CSS easier to track down. I doubt it, but until a browser implements these, it will be hard to determine if that is true.

Anyway.  The good news here is that this is the editor's draft, not the recommendation. This means that now is the time to start analyzing this spec and commenting on it. So what do you think?

 

Aside on W3C Drafts

It's important to note that a "Working Draft" is a pretty early stage of the W3C recommendation process.

W3C follows these steps when advancing a technical report to Recommendation.

  1. Publication of the First Public Working Draft.
  2. Last Call announcement.
  3. Call for Implementations.
  4. Call for Review of a Proposed Recommendation.
  5. Publication as a Recommendation.

I believe we are between steps 1 and 2 at the moment. Also relevant:

Purpose: The publication of the First Public Working Draft is a signal to the community to begin reviewing the document.

So to be clear, we're supposed to be commenting at this stage.

Published at DZone with permission of Terrence Ryan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)