- From: John Daggett <jdaggett@mozilla.com>
- Date: Mon, 16 Sep 2013 20:28:58 -0700 (PDT)
- To: John C Klensin <john+w3c@jck.com>
- Cc: Richard Ishida <ishida@w3.org>, W3C Style <www-style@w3.org>, www International <www-international@w3.org>
John Klensin wrote: >> The existing unicode range syntax has been implemented in CSS since >> 2.1 as part of the tokenizer. And both Webkit and IE support the >> @font-face rule unicode-range descriptor syntax defined in the >> current spec. So at this point, regardless of the subtle >> advantages of one syntax versus another, the point is moot I think. >> Unless we feel there is a strong reason to break existing >> implementations, we need to live we the current syntax. > > I don't think anyone has suggested changing the syntax. At least I > haven't. The issue, at least IMO, is _only_ the language and > notation used to talk about it. Here, I think that means sticking > with "U+" instead of raw hex for several reasons (in other words, I > think I'm agreeing with you). In another case, it means avoiding > words like "valid" unless you are willing to go to the effort to > define exactly what you mean. And, in the "font" case, it means > pinning down "available" to what you really mean. At this late point, we really need to be talking about specifics. Given that the spec has been updated to remove the use of "valid" in the description of 'unicode-range' values (I18N-Issue-296) and you seem to be saying that 'u+....' syntax is acceptable, could you point out what precisely you'd like changed? Is there something in the details of the font matching algorithm which precisely describes how the 'unicode-range' descriptor value is used that you think is misleading or not clear? Regards, John Daggett
Received on Tuesday, 17 September 2013 03:29:28 UTC