- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 4 May 2014 11:37:35 -0700
- To: Peter Moulder <pjrm@mail.internode.on.net>
- Cc: Simon Sapin <simon.sapin@exyr.org>, W3C Style <www-style@w3.org>
- Message-ID: <CAAWBYDC696WUCM1A3mO7A+t+eQKAk110Uqgc0eR3Aq26sy5rhw@mail.gmail.com>
On May 3, 2014 2:41 AM, "Peter Moulder" <pjrm@mail.internode.on.net> wrote: > > On Fri, Apr 25, 2014 at 12:22:53AM +0100, Simon Sapin wrote: > > On 24/04/2014 23:06, Peter Moulder wrote: > > >>No, we *never* make author-defined names case-insensitive, because > > >>"case-insensitive" gets complicated once Unicode comes into play (and > > >>drags along "normalized" and other notions of equivalency). To avoid > > >>all of that, we just mandate case-sensitivity, which means literal > > >>codepoint comparisons. > > >I don't understand this last paragraph. In what way does honouring > > >the quoted sentence of syndata.html get complicated once Unicode comes > > >into play, and how does case-sensitivity avoid normalization issues of > > >whether decomposed and precomposed mean the same thing? > > > > Case-insensitivity within the ASCII range is easy to define: map 26 > > letters, done. > > > > It get complicated quickly with Unicode: you can pick "simple" or > > "full" case folding [and issues with ß, İ] > > I suspect that this is what Tab had in mind too, but these problems don't > apply: if you re-read the first post and its quoted sentence from syndata.html, > it's clear that we're talking about ASCII case folding only. Yes, but mine and Simon's responses still apply. For author defined things, we don't want to privilege ASCII, because that exposes weird things based on normalization. An accented letter may or may not be case sensitive, etc. That's why we only allow css-defined things to be case insensitive, because we stick with the ASCII range for that stuff. ~TJ
Received on Sunday, 4 May 2014 18:38:02 UTC