Re: [css-syntax][css-fonts] Wrapping up the <unicode-range> thing

On 06/26/2015 06:37 PM, Simon Sapin wrote:
> On 22/06/15 17:26, Tab Atkins Jr. wrote:
>> So I think there are two ways we can handle this:
>>
>> 1. Abandon the project, restore <unicode-range-token>, and live with
>> the fact that we have a weird almost-useless token that will
>> occasionally cause problems for authors in unrelated contexts.  (We
>> can't even really do something like make Selectors treat unicode-range
>> specially, because it can cut selectors in pieces - "u+area" parses as
>> a urange(a) ident(rea)!)
>
> Not sure if this is a good idea, but we *could* handle that in the Selectors grammar as well. u+a/**/rea would also parse,
> which we might not want, but it’s much harder for authors to accidentally do that than u+a.
>
>
>> 2. Produce a new, reliable syntax for unicode ranges, and keep around
>> the old version for back-compat, with a warning that some values won't
>> parse correctly.  The most obvious fix is to just replace the + with a
>> -, like "U-0404", "U-400-600", or "U-4??".  This makes the entire
>> thing an ident, which keeps around the characters properly (or an
>> ident followed by some ? delims, which is also fine).
>
> `unicode-range: U+04e4` works today in multiple browsers. Breaking this seems worse than the u+a selector not working.
> (Introducing an alternative unicode-range syntax will not help existing unmaintained content.)

I agree with Simon. We should not break unicode-range syntax here.

If it's possible to fix this by munging the Selectors grammar,
that seems like the best option. I'd argue that we may want to
allow implementations to use context-specific parsing rules as
well, if they want to go that route instead, so the UA would be
allowed to either accept or reject u+a/**/rea. (A full CSS parser
might not want to do that, but a Selectors parser shouldn't have
to deal with unicode-range token munging. Ditto An+B, now I think
about it.)

~fantasai

Received on Saturday, 27 June 2015 08:54:07 UTC