- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 9 Jan 2013 23:06:48 -0800 (PST)
- To: W3C Style <www-style@w3.org>
- Cc: www International <www-international@w3.org>
Richard Ishida wrote: > Selectors and HTML attribute values do NOT match where case is > different. Class names using .classname syntax in the selector are a > variant of this that produces the same results except for Opera, > which matches regardless of case (though doesn't match general > attribute values). I don't see distinct problems with class name matching in Opera, id's and class names are matched case sensitively as in other browsers. For attribute values, your statement is not entirely correct, browsers differ in the type of case matching used when matching attribute values. Firefox does case sensitive matching, other browsers do roughly C+S case insenstive matching (exact results don't always match, Opera is different compared to Webkit and Webkit doesn't handle non-BMP codepoints correctly on OSX). See this testcase: http://people.mozilla.org/~jdaggett/tests/casesensitivity-classid.html Note the handling of lang tag values. As Boris mentions, several of these cases have been fixed in Firefox nightlies, it's now more correctly case sensitive. > Counters are a little more complicated. Basically, if the > counter-increment property and counter function refer to a user > defined counter style using different casing, the display fails. > Otherwise, case is irrelevant. This same behaviour occurred whether > the names were in ASCII, Latin1 or Cyrillic characters. This is actually incorrect, user-defined counters are matched case sensitively, consistently across user agents. Several of the tests incorrectly assert that a case-insensitive match occurred, specifically the tests where the counter name used in the counter-reset declaration used a different case than the one used in the counter-increment and counter declarations. For example, case-conversion-021 [1]: Assertion: If the name supplied in the counter-reset property is cyrillic and lowercase, it will match an the counter-increment property and counter function when they both have uppercase versions of the name. Source: body { counter-reset: control 0; counter-reset: рускии; } div#one p { counter-increment: control; } div#one p:before { content: counter(control, lower-latin) ' '; } div#two p { counter-increment: РУСКИИ; } div#two p:before { content: counter(РУСКИИ, lower-latin) ' '; } Here the counter in the counter-reset declaration does *not* match with the counter used in div#two. Change the counter name to 'bongo' in the counter-reset declaration to convince yourself of that. > I tested in Firefox, Opera and Chrome on Mac and IE9 on Windows7, > and got the same results. (These are standards-mode tests.) You need to test with a wider range of codepoints before making assertions about consistency. I think you'll find a wider range of results. Regards, John [1] http://www.w3.org/International/tests/html-css/generate?test=case-conversion-021
Received on Thursday, 10 January 2013 07:07:16 UTC