Case Sensitivity in CSS [I18N-ACTION-171]

Hello CSS,

In our most recent teleconference [1], I was tasked [2] with conveying the Internationalization working group's comments to CSS.

I18N has considered our long thread of conversation, various tests produced by John Daggett, Richard Ishida, and myself, and other comments and has these recommendations as a result.

Case Sensitive comparison: Case sensitive comparison is the best choice for existing case-sensitive items and for any new features added to CSS. It's the easiest for content authors to understand and manage, has good performance, is straight-forward to implement, and does not disadvantage any language community. We note that most comparisons in CSS are actually case-sensitive.

We believe you should define case-sensitive comparison using the same rules and terms that HTML5 does. Our specific resolution [1] was:

--
We would recommend that CSS adopt case sensitive comparison going forward for all identifiers and language elements, except where legacy considerations apply
--

Case Insensitive comparison: Where CSS cannot be case-insensitive for legacy reasons or for implementation choice reasons, the I18N WG recommends that comparison be done using Unicode "common" plus "full" case fold mapping, as we previously recommended. Suggestions that this is hard to implement or low-performance are, in our opinion, unfounded, as the mapping consists of a relatively small table. There is a demonstration implementation in JavaScript [3] and we have confirmed with our Unicode colleagues that this is the right approach [4].

That said, there is an existing special case of Unicode case folding in use in HTML5 and which is applicable to all or nearly all CSS case-insensitive comparisons. When the compared namespace is restricted to the US-ASCII 7-bit range of characters, so-called "ASCII case insensitive" (ACI) comparison may be used. ACI is a direct subset of the Unicode case fold that we recommend and is appropriate for the ASCII-only cases in CSS.

Currently, as far as we are aware, CSS's only case-insensitive features are restricted to ASCII namespaces and so could have ACI applied to them. The I18N WG, therefore, is "okay" with CSS defining ACI for these comparisons. The same text that HTML5 uses to define ACI should be used by CSS.

If CSS were to add a feature in the future that was not strictly limited to an ASCII namespace and which was defined as case-insensitive (which we don't recommend), then Unicode case folding should be the algorithm used in comparison. Some working group members would prefer if you just defined Unicode case folding for the ACI case to guard against future inconsistencies, as we don't believe there is any harm or negative impact from doing this (and because it addresses the quirks mode problem??).

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.

Regards (for I18N),

Addison

[1] http://www.w3.org/2013/01/09-i18n-minutes.html#item07

[2] http://www.w3.org/International/track/actions/171 
[3] http://inter-locale.com/test/css-case-sensitive-demo1.html 
[4] https://lists.w3.org/Archives/Member/member-i18n-core/2013Jan/0003.html 

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Received on Tuesday, 15 January 2013 16:59:27 UTC