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 22:04:55 -0800
Message-ID: <CAAWBYDAnnd0kXLszUVWePi38J=yLE5jDJUzg-CU9eSPp9-t=BQ@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 9:54 PM, John Daggett <jdaggett@mozilla.com> wrote:
> Tab Atkins wrote:
>> > Please let us know if CSS agrees with the above positions and/or
>> > what concerns you have. We look forward to reviewing changes to
>> > CSS addressing this issue in the near future.
>> The only thing I disagree with is the recommendation that CSS be
>> generally case-sensitive for new features.  This should be nuanced:
>> for consistency with the existing language, anything related to CSS
>> values should be CI.  If we were to, say, design a completely new
>> type of selector, however, it should be CS, as that agrees with
>> Selectors in general.
> What does "anything related to CSS values should be CI" apply to?
> Given that all existing values in CSS have been restricted to ASCII
> keywords, what is the situation where a value would need to be matched
> using Unicode case insensitivity?

The *exact things that sparked this discussion* - user-defined
identifiers, particularly those that occupy the same name-space as
language-defined ones (custom property names, counter styles,

> The specifics of this discussion are related to whether user
> identifiers are matched case sensitively, ASCII case insensitively or
> Unicode case insensitively.  If user identifiers are matched case
> sensitively then what is the scenario where Unicode strings need to be
> matched case insensitively?

User identifiers should not be matched CS.  I know that was the i18n
WG's recommendation, but it's not usable given the things I mentioned
above.  Given that, I'm fine with their lesser recommendation of using
a simple case-folding that can be done eagerly.

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

Received on Wednesday, 16 January 2013 06:05:41 UTC

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