- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 19 Apr 2016 15:40:09 -0700
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: www-style list <www-style@w3.org>
On Tue, Apr 19, 2016 at 5:34 AM, Simon Sapin <simon.sapin@exyr.org> wrote: > On 12/04/16 22:37, Tab Atkins Jr. wrote: >> >> I want to go ahead and resolve this. I can see three options: >> >> 1. Keep what I'm currently doing. This requires browsers to hold onto >> the string representation of numeric tokens (numbers and dimensions) >> at least through initial parsing (longer if they're used in a custom >> property). >> >> 2. Abandon this effort, go back to having a special unicode-range >> token. Accept that this is weird and there are stupid side-effects, >> like some selectors not working. >> >> 3. Define a new <urange> syntax that's actually simple to obtain from >> the existing tokens¹. Deprecate the old syntax; require UAs to accept >> the old syntax in the 'unicode-range' descriptor, but don't define how >> they should do so. (Current UAs use context-sensitive retokenizing, I >> think - once they realize they're in a unicode-range descriptor, >> they'll retokenize the original text according to a special set of >> rules.) >> >> Thoughts? >> >> ¹ Simplest change is just to replace the + with a -, so you write >> `U-2016` for ‖. This makes unicode ranges always a single IDENT token, >> plus possibly some trailing '?' DELIM tokens. You then have to parse >> the token's value to make sure it's a valid range, but that's way, way >> easier than the garbage fire I have to deal with from today's syntax. > > > > How about this? > > 4. Same as 2, but tweak the Selector grammar to interpret unicode-range > tokens that don’t have question marks as: a type selector "u", followed by a > next-sibling combinator, followed by another type selector. > > It’s weird, but it seems less messy to me than the alternatives. Yeah. It really fucks up the grammar something *fierce*, so I think I'd have to do it as a preprocessing step before matching the actual Selectors grammar. And anything else that ever wants to use a + is similarly affected; we seem to have settled on requiring spaces around math + and I don't expect us to use + for anything else, but custom properties would be stuck with this gotcha. :/ ~TJ
Received on Tuesday, 19 April 2016 22:40:56 UTC