W3C home > Mailing lists > Public > www-international@w3.org > January to March 2013

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

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

Hi Addison,

Thanks for putting together this summary of the I18N WG discussion!

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

Great, sounds good.

> We believe you should define case-sensitive comparison using the
> same rules and terms that HTML5 does.

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

Agreed, I think we should sync the definition used within CSS for case
sensitive and ASCII case insensitive matching with the definitions
used in HTML5.  Right now, the CSS3 Syntax spec has a well-defined but
awkward definition of "ASCII case-insensitive" [1] and the Selectors 4
spec has a different, slightly fuzzy definition of the same [2]. I
think we should resolve to define both case sensitive and ASCII case
insensitive matching using the same wording used in the HTML5 spec
[3], it's simpler and better.  Maybe the Selectors 4 spec could
reference the CSS3 Syntax spec?

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

While I understand your point, I really think ASCII case insensitivity
should be clearly separated from Unicode case insensitivity.  Part of
the existing set of edge case differences in user agent behavior
relates to the conflation of these two concepts (e.g. does the kelvin
character match a "k" in a tagname?).  ASCII case insensitivity is
simple to define clearly while this entire discussion underscores the
relative complexity of Unicode case insensitive matching (i.e.
normalization required or not, which type of case mappings, C+F or
C+S, and whether the matching is language neutral or not).


John Daggett

[1] http://dev.w3.org/csswg/css3-syntax/#ascii-case-insensitive
[2] http://dev.w3.org/csswg/selectors4/#case-sensitive
[3] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#case-sensitivity-and-string-comparison
Received on Wednesday, 16 January 2013 02:44:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:34 UTC