- From: Zack Weinberg <zackw@panix.com>
- Date: Sun, 1 Sep 2013 12:17:17 -0400
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Daggett <jdaggett@mozilla.com>
Looks good to me. Irrelevantly (but I happened to notice this while looking over the changes), my last name should be spelled "Weinberg", not "Weinburg", in Issue 3. On Sun, Sep 1, 2013 at 11:43 AM, Simon Sapin <simon.sapin@exyr.org> wrote: > Hi, > > The Syntax ED had a some changes to the <unicode-range> token from CSS 2.1 > where it tried to make the syntax closer to what @font-face accepts, parse a > numeric range as soon as in the tokenizer, and do some range normalization. > > > I just "reverted" these changes, and wrote a definition that matches CSS > 2.1’s idea of what <unicode-range> is: > > https://dvcs.w3.org/hg/csswg/rev/dec8752a6390#l3.1 > > Instead of a numeric range, <unicode-range> tokens now have a "start" and an > optional "end", each made of one to six code points. Parsing this into a > numeric range is left to the Fonts spec (the only one where <unicode-range> > is ever valid,) which it already defines. > > > Reasoning: > > * This makes Syntax agnostic to the exact treatment of <unicode-range> in > the Fonts spec. For example, Fonts recently changed to make ranges ending > outside of Unicode invalid instead of clipping them. Compare: > > http://www.w3.org/TR/2013/WD-css3-fonts-20130212/#unicode-range-desc > http://www.w3.org/TR/2013/WD-css-fonts-3-20130711/#unicode-range-desc > > * Yes, CSS 2.1’s definition is silly and allows invalid ranges such as > U+1?5-300, but changing it does not buy us anything. It’s fine to have > absurd input be valid at the Syntax level and rejected by a given > property/descriptor/selector/etc. > > > Cheers, > -- > Simon Sapin >
Received on Sunday, 1 September 2013 16:17:39 UTC