CSS Variables... A major request from the Web Authors' community since 1998...

Dave Hyatt and I shaped the first concrete public proposal in 2008 but the CSS Working Group could not reach an agreement about it. Variables, constants, mutable constants, OM or no OM, we had endless "religious" discussions about that and Hyatt finally removed his implementation from WebKit.

Then Tab Atkins made a breakthrough last february proposing a much better CSS integration, a model that fits nicely with what we already have. But then we had a problem with the $foo syntax everyone was asking for. Let me explain...

First, the proposed spec is NOT about variables and I seriously wonder if we should not change the title of the document. You may call the feature it introduces "variables" but at the deeper level, that's not about variables. That about Inherited User-Defined Properties. Don't take that as some political correctness or a blurb hiding the reality of the feature. The spec is really about letting you define your own properties and reaching their cascaded values. For instance:

div > p {
var-myprop: 1;
}

p {
var-myprop: 2;
}

In the above case, what will be the value of var(myprop) in a p contained into a div? Right, it will be 1 because the first rule has a higher specificity than the second one... Clearly, these beasts are not variables in the usual acceptance of the term.

Second, how are we going to use the values specified that way? We considered data(myprop), var(myprop) and $myprop. And despite of all the arguments expressed by the community in favor of the latter, the CSS WG decided during its recent San Diego face-to-face meeting to not follow the $foo path: $foo for the getter is too similar to a programming language, leading to confusion. The $ notation is used by preprocessors and script-based toolkits all over the place, it deeply conveys a notion of "programming language variable" or "preprocessor macro". And that's not what this spec is about since the feature introduced by the current spec shows important restrictions a variable or macro would not show:

  1. the value must be a set of valid CSS tokens; don't think of a preprocessor, don't dream of a partial string replacement. I repeat: a set of valid CSS tokens.
  2. you can't use the getter anywhere in CSS Stylesheets. You can use it only on the right-hand side of declarations (in other tems, after the colon in a '<property> : <values>' style declaration).
  3. we need an optional second argument to the getter giving a fallback value if the user-defined property is not set at all on the element.

Before shouting, don't misunderstand us: we clearly see the simplicity, readability and maintainability of the $foo syntax and we perfectly understand why the community prefers it. Being ourselves coders and implementors, we're used to manipulate $-based notations. But running that path implies too much confusion about our feature, will then lead to errors in live stylesheets, impacts existing CSS preprocessors that will have to change their own syntax to avoid collisions with ours, and will block us if we decide in the future to add real $-based macros to CSS. Again, 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. We may reconsider this decision in the future (don't forget the spec is only a Working Draft at this time) but this will require solving all the issues detailed just above. Thanks.