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

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

From: Simon Sapin <simon.sapin@exyr.org>
Date: Tue, 19 Apr 2016 14:34:50 +0200
To: www-style@w3.org
Message-ID: <571625EA.1030403@exyr.org>
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.

-- 
Simon Sapin
Received on Tuesday, 19 April 2016 12:35:18 UTC

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