W3C home > Mailing lists > Public > www-style@w3.org > February 2016

RE: [css-variables] Why so inefficient?

From: Francois Remy <francois.remy.dev@outlook.com>
Date: Tue, 23 Feb 2016 13:58:46 -0800
Message-ID: <DUB408-EAS39487923AA40C1864BC1C6A5A40@phx.gbl>
To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'Patrick Dark'" <www-style.at.w3.org@patrick.dark.name>
CC: "'darkdragon'" <darkdragon-001@web.de>, "'www-style list'" <www-style@w3.org>
> > One reason it's onerous aside from the verbosity, is that if I create
> > a custom property like --color, then try to copy and paste what I just
> > typed to multiple locations, I can't do that without first typing
> > "var(" at the beginning of what I pasted and ")" at the end of what I
> > pasted, then copying that before continuing the paste process. In case
> > it's not obvious, I arrive in this situation because it's typically
> > the case that I'll write part of a style sheet before deciding that I
> > need variable to ensure that certain parts of the style remain consistent.
> Yeah, I sympathize with this.  But I disagree that it's sufficiently onerous to
> justify the drawbacks of bare keywords.
> For example, I *messed up* when I was speccing @counter-style.  By
> allowing any arbitrary name, I had to produce a list of disallowed keywords
> (and keep it updated, and swallow the possible compat pain if in the
> meantime someone *used* a name that I'm now disallowing), and had to
> add several subtle and annoying tweaks to the spec, complicating it and
> implementations.  If I were writing it today, I'd require the @counter-style
> name be a <custom-ident> (the -- prefix) so they were distinguishable from
> built-in keywords and could never collide.  Same with @keyframes - handling
> an arbitrary keyframes name in the 'animation' shorthand is really kinda
> messed up, and required us to define some pretty weird parsing rules to
> cover it.  Any future user-defined names are probably gonna be <custom-
> ident>s from now on, to avoid these issues.

A better solution is to use strings. I would love animation-name, transition-property, etc... to accept strings instead of identifiers.
Arbitrary Identifiers are required for compat reasons but could be considered a deprecated feature.

I see no pain in defining that those "user-defined identifiers" cannot start with two dashes, because that was most likely invalid prior to the changes we made to allow --custom-properties to be valid, so no one should use this at this point. 

If you ever need to reference a custom property by name, instead of writing >>transition: --foo 5s<< you would write >>transition: "--foo" 5s<<. This is very similar to how "font-family" works, where you can use both strings and identifiers for compat reasons. That looks reasonable to me.

> (Actually, Firefox is the only one with @counter-style support.  I wonder if I
> could get them to make this change. I'll make another thread. ^_^)
> This would, obviously, conflict with treating bare custom-idents as variable
> references.

See suggestion above.
Received on Tuesday, 23 February 2016 21:59:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC