W3C home > Mailing lists > Public > www-style@w3.org > November 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 19 Nov 2014 15:24:21 -0800
Message-ID: <CAAWBYDA-1T5zAW5B0ZFiKOM-HFFb9-3LLcVWrpfgBDEpYzMmvQ@mail.gmail.com>
To: Zack Weinberg <zackw@panix.com>
Cc: www-style list <www-style@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:49 UTC