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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 15 Jan 2013 23:16:08 -0800
Message-ID: <CAAWBYDCtbQvgU5W6zDK=TkX1UZ4sM=htyJ6DKJz-WK6C8RYhhw@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: "CSS WWW Style (www-style@w3.org)" <www-style@w3.org>, WWW International <www-international@w3.org>
On Tue, Jan 15, 2013 at 11:03 PM, John Daggett <jdaggett@mozilla.com> wrote:
> 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?!?

This was established very early on, at the last f2f: using CS matching
for user idents makes it confusing when you mix language-defined and
user-defined idents in the same namespace, such as custom property
names and counter-style names.

(Counters being matched CS is unfortunately inconsistent with this,
but it's also very likely changeable.)

> 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.

Using ASCII CI for user-defined idents (or equivalently, requiring
them to be ASCII-only), is unacceptable to the i18n WG and several
members of our own WG.

Received on Wednesday, 16 January 2013 07:16:55 UTC

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