[css-variables] TLDR: get free hugs by reading this message entirely

Hi everybody,

I suppose most of you heard about the CSS WG decision to 
rule out the $foo syntax from the [css-variables] specification. 
If not, then now you have :-) As an initial opponent of the $foo 
syntax, I can’t really say I’m unhappy of this decision, whose 
catalysts includes :

    - Difficulty to use $ on both sides of the declaration because 
it breaks existing CSS tools (and syntax) and was proven confusing.

    - Confusion between “templating macros” (aka Preprocessor 
Variables) and “custom properties” (aka CSS Variables), which 
includes traditional CSS Properties exclusives like cascading, 
inheritance and element-local scope (which mean they are not 
‘stylesheet-local’ or ‘rule-local’ like preproc variables).

    - As such, a necessity to reserve the $ token for future, more 
macro-like microsyntaxes (selectors variables, mixins, extensions...) 
which will please the “preprocessor” people a lot more than the 
current proposal, which should never have been called “variables” 
by the way.

However, I’m not really satisfied either with the current state of the 
[css-variables] draft, which was rolled back to the initial “var-“ and 
“var()” syntax. I’m not going to repeat here the whole discussions 
that lead us to here, since interested people can use the archives 
to discover it in more details. 

What I would like to point out is that the “var-“ and “var()” 
syntax triggered a lot of constructive comments and that ruling 
them out with such a rollback is not the way we’re going to make 
any progress on the matter. I’m certainly under the impression that 
we need to look for facts and not for opinions to make this whole 
specification progress.

Really, few people tried to collect previous usage of custom 
properties like I did [1]. Brian and I crafted real-life examples for 
our spec [2] and demonstrated custom properties possibilities, 
something that the working group failed to achieve until now. 

For a use-case driven working group, this is not what I’m going
to call a success.

[1] http://fremycompany.com/BG/2012/My-research-about-css-custom-ndash-CSSWG-882/
[2] http://fremycompany.com/TR/2012/ED-css-custom/#sample-global

As the community couldn’t read in your minds, the community 
didn’t understand the [css-variables] thing; and it’s not as if I 
did not warn about it in the past [3]. 

[3] http://lists.w3.org/Archives/Public/www-style/2012May/1027.html

Maybe it’s time to take real-life data in consideration in the 
decisions the WG make about [css-variables]. I heard clearly and 
I agree with the current decision to rule out the $foo syntax. That’s 
fine. I’m happy with it. Now, let’s talk about what to do of the 
[css-variables] spec.

Firstly, for the sake of -----, rename that spec. Everybody [4] seems 
to agree that “Variables” is problematic and that “Custom Properties” 
would be way better. Let’s just go for it. Why does it take so much 
time to rename a specification?

[4] https://twitter.com/glazou/status/235813031605575681
[4] https://twitter.com/chriseppstein/status/236116588439416832
[4] http://www.xanthir.com/b4KT0#4KT0-4
[4] http://fremycompany.com/BG/2012/Explaining-CSS-Custom-Properties/
[4] ...

Secondly, the community is in demand of being able to target any 
property in the future using references, and not only custom 
properties. [5] parent.font-size is huge.

[5] https://twitter.com/chriseppstein/status/236116588439416832
[5] In fact the CSS Custom Properties was made with that in mind

Oh! I heard you swear!  

Meanwhile, I continue to say that, yes, it’s possible. We want to target 
the specified value and this value doesn’t depend on any other property’s 
value, just on what is written in the CSS file (all details in my previous 
mail [6]). That way, I can target “background-color” and use it for my 
“outline-color”. This is huge.

[6] http://lists.w3.org/Archives/Public/www-style/2012Jun/0277.html

Thirdly, we need a decent syntax. Seriously, I did take the time to write 
down all the “requirements” of a good CSS Custom Properties syntax. 
At the time, I just tried to make sense. The current var- and var() syntax 
just does *NOT* make sense, in the big picture.

Alternatives do exist. Here are a few :

    - Go with the current CSS Custom Properties draft:

        .x { my-property: value }
        .x .y { color: $(my-property) }


    - Go with the {} island proposal :

        .x { my-property: value }
        .x .y { color: {my-property} }


    - Go with the OO proposal :

        .x { my-property: value }
        .x .y { color: self.my-property }


Those alternatives are easily extensible to “parent-var” and “fallbacks” :
    
    - Go with the current CSS Custom Properties draft:

        .x .y { 
            my-property-bak: $parent(my-property, fallback);
            my-proprety: $parent(my-property-bak, fallback);
        }


    - Go with the {} island proposal :

        .x .y { 
            my-property-bak: { parent.my-property | fallback };
            my-proprety: { parent.my-property-bak | fallback };
        }


    - Go with the OO proposal :

        .x .y { 
            my-property-bak: firstOf(parent.my-property, fallback);
            my-proprety: firstOf(parent.my-property-bak, fallback);
        }


The decision to rollback the $foo syntax must not come with a 
decision not to consider any new option, certainly given the fact 
that alternatives that were not using the “$” symbol were declared 
“out” at some point, and no announcement has been made before 
the f2f that this restriction was going to be lifted (nor was it even 
hinted).

We certainly need more reflection. I’m not sure we have the best 
solution in hand now. But I’m sure the current one is certainly not 
the best one of those we have.

Kind regards,
François


--------------------------------------------------------------------------------

And here are the