W3C home > Mailing lists > Public > www-style@w3.org > October 2012

Re: [css3-fonts][css-variables][css-counter-styles-3][css3-values] Case sensitivity of user-defined identifiers

From: Jonathan Kew <jfkthame@googlemail.com>
Date: Tue, 02 Oct 2012 12:44:47 +0100
Message-ID: <506AD3AF.7090706@gmail.com>
To: www-style@w3.org
On 1/10/12 15:44, fantasai wrote:
 > On 09/30/2012 07:59 PM, John Daggett wrote:
 >> Tab Atkins wrote:
 >>> However, it's very limited - if you write an ident in a language
 >>> other than English, you may very well run up against casing issues
 >>> that should be "obvious" to solve.
 >> I don't understand what this sentence implies.  The existing rule for
 >> CSS is
 >> case-sensitive matching outside the ASCII range.  What are the "casing
 >> issues"
 >> here?  Yes, it's simple and crude and by no means ideal but it is what
 >> it is,
 >> I'm not sure I see "issues" here.
 > It means that Håkon will match HåKoN but not HÅKON.
 > Similarly César will match césar and CéSaR, but not CÉSAR.
 > However John will match john, JoHn, and JOHN.
 > This is, imo, undisputably weird to a user,

+1. Weird indeed, and non-English-speaking users might (reasonably) feel 
they're being treated as second-class citizens.

 > even though it seems
 > straightforward to anyone familiar with character encoding history.

Are we comfortable saddling authors with this ASCII-centric weirdness 
forever just because of an accident of encoding history?

IMO, identifiers should either be case-sensitive for everyone (thus 
avoiding the issue, as per XML), or they should use simple (1:1) 
locale-independent Unicode case folding. Yes, it's not perfect - e.g. 
for the Turks and Lithuanians - but it's simple, predictable, and vastly 
better and more inclusive than the ASCII-case-insensitive anachronism.

Received on Tuesday, 2 October 2012 11:45:13 UTC

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