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

Re: Case sensitivity in CSS: some tests

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>
Message-ID: <2004112728.10086988.1357801608747.JavaMail.root@mozilla.com>
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:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 January 2013 07:07:18 GMT