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

Re: [css-syntax] Removed <unicode-range-token>, please review

From: John Daggett <jdaggett@mozilla.com>
Date: Wed, 19 Nov 2014 00:19:57 -0800 (PST)
To: www-style list <www-style@w3.org>
Message-ID: <1457368363.13233581.1416385197577.JavaMail.zimbra@mozilla.com>

Tab Atkins wrote:

> > The Syntax spec is defining <urange> which is already defined in the Fonts spec:
> >
> >   http://dev.w3.org/csswg/css-syntax/#urange
> >   http://dev.w3.org/csswg/css-fonts/#urange-value
> >
> > The Fonts spec has this wording:
> >
> >   Each <urange> value is a UNICODE-RANGE token made up of a
> >   "U+" or "u+" prefix followed by a codepoint range in one
> >   of the three forms listed below.
> >
> > The much narrower question that I think we should be tackling is
> > what in the sentence above needs to change if the UNICODE-RANGE
> > token definition is removed.
> 
> What needs to change is replacing that sentence with the
> production and algorithm I defined in the Syntax spec.

But why Tab, why?!? You're basically proposing to replace a succinct
definition of valid syntax for <urange> with, um, a monster!

The <urange> definition you've created seems like it's just
cataloging all the possible token combinations that would occur for
valid unicode-range values if the UNICODE-RANGE token is undefined.
But to distinguish valid vs. invalid syntax you still need
additional statements about the exact nature of the range values
(e.g. end is greater than or equal to the start, both start and end
are valid Unicode values, etc.). So I just don't see that you've
defined anything of value for someone writing a CSS parser.

Going back to the original problem, seems like UNICODE-RANGE tokens
outside of @font-face rules can be dealt with by simply
reinterpreting them as <ident><plus><ident> tokens by the parser in
places where they pop up. Not pretty, I realize, but it seems far
easier to detail then what you're proposing.

John Daggett
Received on Wednesday, 19 November 2014 08:20:25 UTC

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