RE: [css-variables] -- considered harmful

> > 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.
> > 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
> 
> I like the -- prefix.  But var(--foo) is ugly.  If we need to separate the names
> of real properties with custom properties, I think --foo is fine.  Visually it
> works better for me than var-.
> 
> > 2. I still find it incredibly error-prone
> 
> It would be good to know what specifically you find error-prone.
> 
> > 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’m not sure what you gain from outlawing this.  The point of having some
> kind of syntactic distinction between real properties and custom properties is
> so that you don’t need to worry about collisions (as you mention).  I’m also
> not sure how the -- prefix affects this, as you’d have a similar problem with $.
> Unless you are arguing for no syntactic distinction at all between real and
> custom properties?
> 
> ...
> > 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.
> 
> Well, I don’t mistakenly think that the -- in “ls --help" is a decrement
> operation. :-)

Just wanted to mention I share Cameron's opinion until here.


> If I were starting over, I’d use non-var()-wrapped custom property names to
> expand variables, and some other syntax like custom(foo) in transition-
> property:
> 
>   :root {
>     --theme-main-color: #123;
>   }
> 
>   div {
>     background-color: --theme-main-color;
>     transition: 1s custom(theme-main-color);
>   }
> 
>   div:hover {
>     --theme-main-color: #456;
>   }
> 
> You’d want to keep var() around in case you needed to supply a fallback
> value.

Like you, I believe the var(...) syntax isn't perfect. I think your proposed solution also has issues, though. Transition-name should take property names consistently. It should have been the case you need a wrapper for all properties or for none, but I don't like to discriminate in this case.

I think we can do better for people using custom properties as variables, though. Maybe we should allow $theme-main-color as an alias to var(...), though. This is retro-compatible with the current spec and may relieve some of the current complains. We can still use the $ sign for other kinds of macro/replacements in compound forms like $$ or $(...) so this doesn’t prevent us from exploring other options in the future.

By the way, I'm also still unhappy of "box-shadow: var(--link-shadow, 3px red, 2px blue)" being specced instead of "box-shadow: var(--link-shadow || 3px red, 2px blue)". If we are going to update the spec, could we consider this change?

Regarding the use of the -- prefix for future user identifiers that Xidorn advocated for, I would not recommend it. User identifiers look like a mistake to me, and I believe we should prefer strings or function notations in those cases going forwards to avoid any issue and be future-proof. This is similar to what we did in grid-template-areas and I somehow regret we didn't follow the same pattern in grid-area.

Received on Wednesday, 4 November 2015 06:21:17 UTC