Re: [css-syntax] Dropping <number-token> representation, and its effects on <urange>

On Wed, Nov 19, 2014 at 2:47 PM, Zack Weinberg <zackw@panix.com> wrote:
> On Wed, Nov 19, 2014 at 3:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> In the telcon today, dbaron expressed concern that the definition of
>> <urange> requires looking at the "representation" of <number-token>s
>> and <dimension-token>s.  (The "representation" of a numeric token is
>> the actual text used to write the number, including leading 0s,
>> leading + sign, original base and  exponent when using scientific
>> notation, etc.)
> ...
>> So, that leaves us with three possible resolutions to the <urange> thing.
>>
>> 1. Leave it as it is.
>> 2. Drop the representation requirement, and rejigger the <urange>
>> definition to account for that.
>> 3. Revert this whole thing, and restore <unicode-range-token>.  This
>> requires us to fix the original problem some other way.  As a
>> refresher, the original issue was that "u+a { ... }" is a syntax
>> error...
>
> Option 3a: Restore <unicode-range-token> but declare that it is only
> considered as a tokenization within @font-face { ... }, or even only
> within the unicode-range: descriptor within @font-face.
>
> I can't say that I *like* this, but that's because I am
> philosophically not a fan of special tokenizer productions that only
> apply in specific grammar contexts -- can anyone think of a
> *practical* problem?  It's not any worse than unquoted url() in terms
> of code, it can't change the boundaries of a top-level construct, and
> the only other issue that comes to mind is that it'll make it harder
> to use <unicode-range-token> somewhere else in the future.  But I
> don't know that there *are* other uses, so.

That requires a vastly more complicated change, switching the Syntax
module from being separate tokenizer/parser steps to being integrated,
with a lot more state being thrown around.  And it doesn't help us if
we ever want to use <urange> in another property or context, which I
think is plausible.

~TJ

Received on Wednesday, 19 November 2014 23:25:07 UTC