- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 15 Jan 2013 23:03:21 -0800 (PST)
- To: "CSS WWW Style (www-style@w3.org)" <www-style@w3.org>
- Cc: WWW International <www-international@w3.org>
Tab Atkins wrote: > > 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. Huh? Counters are matched case sensitively across all user agents now. ASCII case insensitivity is used for situations where an ASCII keyword is matched, which is a different case altogether from a user-defined string. An author can use whatever casing they like for their own identifiers, what huge utility is there to caseless matching of these identifiers that warrants introducing a *third* type of case matching to web platform?!? I too initially felt that some form of Unicode case insensitive matching should be used for consistency reasons but upon reflection I don't think the actual usage in question justifies the added work. If normalization and language-specific tailorings are specifically excluded, the implementation cost isn't so high but I think adding a third flavor of case matching isn't really something authors are begging for, especially given that so many other parts of the web platform already use case sensitive matching or simply require ASCII-only identifiers. Regards, John
Received on Wednesday, 16 January 2013 07:03:53 UTC