- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 13 Nov 2014 21:03:11 -0800
- To: John Daggett <jdaggett@mozilla.com>
- Cc: www-style list <www-style@w3.org>
On Thu, Nov 13, 2014 at 7:42 PM, John Daggett <jdaggett@mozilla.com> wrote: > Tab Atkins wrote: >> Per the resolution from the 2014-07-02 telcon, I've removed the >> <unicode-range-token> from Syntax entirely, and replaced it with a >> <urange> microsyntax: <http://dev.w3.org/csswg/css-syntax/#urange> >> >> If you're interested in this kind of thing, please give it a look-over >> and verify that I haven't missed any cases or made any mistakes. It >> was simpler than I thought it would be to spec out. > > Tab, this doesn't seem like a good change. The underlying problem is > in the *tokenization* aspect of UNICODE-RANGE. If you eliminate the > token, I'm not sure I see the reason to try and describe the syntax > within the Syntax spec when it's used in only one place, namely the > definition of the 'unicode-range' descriptor. It has to be described somewhere, and as a "weird syntax" like An+B that involves reinterpreting tokens into a completely different meaning, it seemed appropriate to put it into here. If you'd rather have it in Fonts, that's fine. It just needed to be written. >> In section 7.1: >> >> To determine what codepoints the <urange> represents: >> >> 1. If end value is greater than the maximum allowed code point, set >> it to the maximum allowed code point. > > No, this is invalid syntax and the descriptor defintion should be rejected. > >> 2. If start value is greater than end value, the <urange> >> represents an empty range of codepoints. > > Ditto. Plus you introduce serialization problems by allowing "empty > range". I went through this with the Fonts spec, that's why it isn't > defined this way. :) Sure, I can just make those both invalid <urange> rather than empty or truncated. Not a problem. ~TJ
Received on Friday, 14 November 2014 05:03:58 UTC