Re: [css-syntax] <urange> and it's problems

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