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

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

From: Zack Weinberg <zackw@panix.com>
Date: Wed, 19 Nov 2014 17:47:34 -0500
Message-ID: <CAKCAbMhPzvYydEs02wbtg5KyG0J-wiBmEehFTBbixNe8q_n_jw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
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.

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC