W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: Case Sensitivity in CSS [I18N-ACTION-171]

From: John Daggett <jdaggett@mozilla.com>
Date: Tue, 15 Jan 2013 23:03:21 -0800 (PST)
To: "CSS WWW Style (www-style@w3.org)" <www-style@w3.org>
Cc: WWW International <www-international@w3.org>
Message-ID: <1013848004.11961951.1358319801353.JavaMail.root@mozilla.com>

Tab Atkins wrote:

> > HTML5 has clearly adopted a pattern of using case sensitive
> > matching for all string matching not already defined as ASCII case
> > insensitive. I do not see a situation where CSS alone needs to
> > require Unicode case insensitive matching.
> Our problematic cases fall precisely into that bucket - string
> matching already defined as ASCII CI.  For consistency, all of our
> stuff should do the same, at least in the realm of CSS idents and
> closely-related things.

Huh?  Counters are matched case sensitively across all user agents
now.  ASCII case insensitivity is used for situations where an ASCII
keyword is matched, which is a different case altogether from a
user-defined string.  An author can use whatever casing they like for
their own identifiers, what huge utility is there to caseless matching
of these identifiers that warrants introducing a *third* type of case
matching to web platform?!?

I too initially felt that some form of Unicode case insensitive
matching should be used for consistency reasons but upon reflection I
don't think the actual usage in question justifies the added work.  If
normalization and language-specific tailorings are specifically
excluded, the implementation cost isn't so high but I think adding a
third flavor of case matching isn't really something authors are
begging for, especially given that so many other parts of the web
platform already use case sensitive matching or simply require
ASCII-only identifiers.


Received on Wednesday, 16 January 2013 07:03:51 UTC

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