RE: [css-variables] -- considered harmful

Hi Daniel,
> Hi there,
> 
> I just stumbled upon a set of slides authored by Wilson Page from
> Mozilla about WebComponents in Gaia. And in this set, I found the
> following slide (please note these great slides are just a live
> example of CSS Variables usage and I link to a screenshot of them here
> only as such):
> 
>   http://pbs.twimg.com/media/CSyy2UGWcAA2lbh.png
> 
> Reading this slide triggered many, many comments here.
Good press, bad press, the important thing to rule the world is that people talk about you, right? :D

> So I'd like this mailing-list to record my POV on the -- syntax:
> 1. I still find it our ugliest syntactic decision in 20 years

And, without surprise, one of the most controversial one. It is still possible to opt in for a rename but the advantage of the -- syntax was the certainty we would not break the web anywhere we should want to use it in the future: custom pseudos, custom media queries, custom anything.
Another advantage is that, being non-textual, it saved us from the bikeshedding of choosing the prefix. Brian coined "x" but it conflicted with the svg properyty, then I championed "my", some said it was too personal; others wanted "custom", others said it was too long, etc etc etc... I remember this going on for a long time, so that even Brian and myself ended up using no textual prefix our our fork of the custom properties spec at the time. Do we want to return to this state yet another time? The advantage this time is that we have a statu quo, so we are not screwed if we don't have a majority supporting any of the proposals, but still.


> 2. I still find it incredibly error-prone
I'm not sure what you mean here, could you elaborate what you think will be a source of error?


> 3. it allows an author to write the perfectly valid
> 
>    .two-columns {
>      column-count: var(--column-count);
>      -moz-column-count: var(--column-count);
>      -webkit-column-count: var(--column-count);
>      --column-count: 2;
>    }
> 
>    and such a rule seems to me so awful I'm shaking my head in despair.
I disagree with you, this is not how the code would look like. It would look like this:
   * {
     column-count: var(--column-count);     -moz-column-count: var(--column-count);
     -webkit-column-count: var(--column-count);
     --column-count: initial;
   }
  .two-columns {     --column-count: 2   }
  .three-columns {    --column-count: 3  }
which is much better than what the css-without-variables look like, since you should have to repeat all the prefixes everywhere. If we want to do gradients, it becomes even more obvious, as we can reduce the gradient syntax into a template of multiple properties like --gradient-color-stops and --gradient-angle, and use one variable declaration per possible syntax, which at some point have been numerous.


> Custom Properties are - I did not change of opinion - a superb way
> of nicely adding variables to CSS. But first, if they are 'properties',
> I don't think we should be able to give the same name to a property and
> a custom property; one could argue the names will never be the same
> since -- is part of the custom property's name... I'm far from
> accepting that argument as enough. I think we're making a very bad
> decision allowing things like 'background: var(--background)'.
Why do you think that? I'm really curious, as I think this feature is very useful for polyfilling purposes. The whole point of having a custom prefix is we should be free to do whatever we find useful behind it, and it doesn't impact css in general.
Is your comment about the fact you find it too difficult to differentiate between background and --background while scanning the stylesheet? That doesn't seem bad to me as, in the cases I have seen, this was on purpose by the author as the custom property was aimed at replacing the standard property in the stylesheet, but I can get your point for weaker choices like "color" or "background-color". 
Whatever you do, people will still be able to name their things badly, anyway.
> perfectly understand the technical details here, and I am replying it's
> also our duty to care about the non-technical details that matter
> to our main users, web agencies.
> 
> Second, from a readability and maintainance point of view, even $foo
> would be better than --foo. Unfortunately, $foo is impossible to avoid
> collisions with CSS preprocessors. But that's probably not a good enough
> reason to pick up a double dash. If $foo is universally understood as a
> variable, --foo is universally understood as a decrement. A very bad
> choice again.
"Universally" :-)
> It's still time to offer better than what we have now.
> My 0.02€.