- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 23 Feb 2016 15:25:25 -0800
- To: Francois Remy <francois.remy.dev@outlook.com>
- Cc: Patrick Dark <www-style.at.w3.org@patrick.dark.name>, darkdragon <darkdragon-001@web.de>, www-style list <www-style@w3.org>
On Tue, Feb 23, 2016 at 1:58 PM, Francois Remy <francois.remy.dev@outlook.com> wrote: >> > 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. Strings work too, sure. It's also two characters. ~TJ
Received on Tuesday, 23 February 2016 23:26:17 UTC