- 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
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). Cheers, 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:27 UTC