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: Mon, 17 Nov 2014 16:35:37 -0800 (PST)
To: www-style list <www-style@w3.org>
Message-ID: <1293465281.12646193.1416270937438.JavaMail.zimbra@mozilla.com>

Tab Atkins wrote:

>> Tab, we have an existing spec in CR that already defines the
>> unicode range syntax.
> 
> Not really.  The definition of the unicode-range syntax has always
> been in CSS 2.1 Chapter 4 or CSS Syntax.  CSS Fonts defines some
> additional validity rules over the core syntax.

No, CSS 2.1 Chap. 4 only referred to the unicode-range tokenization,
there's nothing there about the actual syntax rules which are far
narrower than what the token allows.

Beyond quibbling over spec history, why do you want to split the
defintion of the syntax across two specs (i.e. Syntax/Fonts) when
it's used in a *single* place, namely the unicode-range descriptor
of the @font-face rule?!? This obfuscates the syntax rules for both
implementors and authors, especially since they will need to read
*both* specs.

>> I do not think it makes sense to either move it out of the Fonts
>> spec or reword it in the way you've done, especially when what
>> you describe is not what is currently implemented. Better to fix
>> existing weaknesses if they exist than to create a whole new
>> description that needs to be vetted again.
>>
>> I think we should narrow the necessary changes to "what about the
>> syntax needs to be reworded if the unicode-range token is
>> removed?"
> 
> Yes, I agree.  What am I doing beyond that now?  All the spec is
> doing is defining what sequences of tokens get interpreted into a
> <urange>, and marking some results from that as invalid <urange>s,
> matching what Fonts specifies. 

You're not just making adjustments to the *existing* definition in
the Fonts spec based on removing the unicode-range *token*, you're
completely writing another new definition of <urange>, one that
introduces compatibility risk. It's confusing and makes extra,
unnecessary work for the group.

Unexpected unicode-range tokenization outside of @font-face rules
(e.g. selectors) is the problem we're trying to solve here. We're solving
no problem by creating a new definition of unicode-range syntax.

John Daggett
Received on Tuesday, 18 November 2014 00:36:06 UTC

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