- From: Francois Remy <francois.remy.dev@outlook.com>
- Date: Tue, 23 Feb 2016 13:58:46 -0800
- 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