- From: John C Klensin <john+w3c@jck.com>
- Date: Fri, 13 Sep 2013 11:00:44 -0400
- To: John Daggett <jdaggett@mozilla.com>
- cc: Richard Ishida <ishida@w3.org>, W3C Style <www-style@w3.org>, www International <www-international@w3.org>
--On Friday, September 13, 2013 05:57 -0700 John Daggett <jdaggett@mozilla.com> 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. In no case do any of these suggested changes require a change in any existing conforming and competent implementation. I'm sorry it is late. I'm even more sorry that it took looking at other comments and having a "right problem, maybe not the right fix" reaction to some of them. I don't think it is in the best interests of W3C or the web to put a spec out there that will mislead some and/or be interpreted in different ways by different people. I felt it was desirable to raise the issues. If you conclude that they are important enough relative to other considerations (including the schedule), I can and will accept that even if I question its long-term wisdom. john
Received on Friday, 13 September 2013 15:01:12 UTC