W3C home > Mailing lists > Public > www-style@w3.org > December 2012

Re: some case-insensitivity cases to test

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 12 Dec 2012 18:13:59 +0100
To: Øyvind Stenhaug <oyvinds@opera.com>
Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>, WWW International <www-international@w3.org>
Message-id: <20121212181359891646.4e9db47f@xn--mlform-iua.no>
Øyvind Stenhaug, Wed, 12 Dec 2012 16:17:04 +0100:
> On Wed, 12 Dec 2012 15:10:35 +0100, Leif Halvard Silli:
>> John Daggett, Wed, 12 Dec 2012 05:10:46 -0800 (PST):
>> 
>>>>  * HTML tag names, attribute names, and attribute values, e.g.:
>>>>      <input> vs <ınput> etc.
>>>>      <select multiple> vs <select multıple> etc.
>>>>      <input type="radio"> vs <input type="radıo"> etc.
>>> 
>>>   http://people.mozilla.org/~jdaggett/tests/casesensitivity-tagnames.html

  [ snip ]
>> If we
>> revise the the results due to this error, then it seems that
>> Chrome/Safari behave like IE10 and FF. My suspicion is that it is the
>> same issue in Opera (Dragonfly would not open).
> 
> It's not clear to me what exactly this test is intended to check,

Yeah, there is no CSS selector involved for the <mark> examples, so I 
don't think it currently is a relevant test.

> but 
> yes - in Opera, like in Chrome/Safari, document.createElement in HTML 
> context converts the kelvin sign to lowercase k. The HTML parsers do 
> not (kelvin sign is preserved if used in tags in the static document 
> source).
> 
> Looking at the DOM tree as displayed in inspectors doesn't really 
> work, though, they seem to do some normalization/conversion of their 
> own. (This includes Firebug and Firefox' built-in inspector.) I used 
> localName instead (e.g. element.localName.charCodeAt(3).toString(16) 
> which gives 212a for kelvin sign and 6b for lowercase k).

In reality, I concluded, before looking in the inspector, based on the 
fact that the kelvin sign is preserved if used in tags in the static 
document. 

But yeah, I now see that e.g. in Safari, then a Cyrillic-Latin  element 
such as <X-МАРК> is fully lowercased in the DOM inspector - but not "in 
reality", where it ought to be ASCII lowercased.

The important conclusion is, I believe, that browsers - for these 
tests[*] and in contrast to what John said, operate with 
ASCII-lowercasing - AKA case-insensitivity, for the selectors.

[*] Other test/knowledge may show different results.
-- 
leif halvard silli
Received on Wednesday, 12 December 2012 17:14:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT