W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [css-counter-styles] case sensitivity of counter-style-name

From: Simon Sapin <simon.sapin@exyr.org>
Date: Fri, 25 Apr 2014 00:22:53 +0100
Message-ID: <53599CCD.9030907@exyr.org>
To: Peter Moulder <pjrm@mail.internode.on.net>, www-style@w3.org
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 depending on whether you accept changing the number of code 
points (ß ⇄ SS), and a few other variations. Then you can chose (or not) 
to apply locale-specific mappings (such as İ in Turkish). But CSS 
stylesheets does not have a locale, and we don’t want to pick one 
arbitrarily for the language as a whole.

Precomposed vs. decomposed combining code points is not directly related 
to case folding but they’re two kinds of normalization. If you’re doing 
one, why not the other?

We chose to ignore all these issues and simply compare code points for 
equality when matching author-defined things. For CSS-defined things, we 
can ensure everything stays within the ASCII range and get away with 
ASCII-only case insensitivity.

Simon Sapin
Received on Thursday, 24 April 2014 23:23:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:42 UTC