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

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

From: Phillips, Addison <addison@lab126.com>
Date: Tue, 15 Jan 2013 09:40:23 -0800
To: "CSS WWW Style (www-style@w3.org)" <www-style@w3.org>
CC: "www-international@w3.org" <www-international@w3.org>
Message-ID: <131F80DEA635F044946897AFDA9AC34773A9D7A258@EX-SEA31-D.ant.amazon.com>
One small nit (thanks to Mati Allouche for pointing it out):

Where it says " Where CSS cannot be case-insensitive for legacy reasons", it should say "case-sensitive"


> -----Original Message-----
> From: Phillips, Addison
> Sent: Tuesday, January 15, 2013 8:59 AM
> To: CSS WWW Style (www-style@w3.org)
> Cc: www-international@w3.org
> Subject: 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 18:04:31 UTC

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