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

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.

zw

Received on Wednesday, 19 November 2014 22:47:56 UTC