RESOLVED CONFIGURATION CHANGED 81752
Selectors should be ASCII case-insensitive in HTML 
https://bugs.webkit.org/show_bug.cgi?id=81752
Summary Selectors should be ASCII case-insensitive in HTML
Anne van Kesteren
Reported 2012-03-21 03:36:08 PDT
Currently WebKit treats Selectors as Unicode case-insensitive, just like the HTML parser they should be ASCII case-insensitive.
Attachments
Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2012-03-21 10:03:09 PDT
This sounds just wrong. Why would ASCII and non-ASCII be different here? Event if WebKit disagrees with every other browser out there, it's still not clear whether we should change this.
Tab Atkins
Comment 2 2012-03-21 12:49:09 PDT
The Selectors spec says that case-sensitivity is defined by the host language. HTML says that it's ASCII case-insensitive only. This matches Gecko. We should make this change.
Alexey Proskuryakov
Comment 3 2012-03-21 14:07:53 PDT
So "AAA" is case insensitive and "ААА" is case sensitive? Does this make any sense outside of spec writing universe?
Tab Atkins
Comment 4 2012-03-21 15:02:19 PDT
You are making an appeal to logic. You must be new to the HTML parser.
Ian 'Hixie' Hickson
Comment 5 2012-03-21 15:08:52 PDT
In the HTML parser, we're ASCII case-insensitive (and not Unicode case-insensitive) so that you can do the logic using only ASCII-range single-byte manipulation. It doesn't make sense for a selector for element "А" to match an element "a" because those elements are different everywhere else too (in XML, where it's case-sensitive, and in HTML, where they're not collapsed to one either).
Alexey Proskuryakov
Comment 6 2012-03-21 15:36:53 PDT
Right. I was talking about class names though - ultimately, these need to be matched according to expectations of the person writing them in their natural language. Doing case-insensitive comparison for ASCII sets the expectation. Perhaps the bug is more specific than what I read into it. A test case would have been helpful.
Anne van Kesteren
Comment 7 2012-03-23 01:37:10 PDT
I included a link. And class names are case-sensitive.
Alexey Proskuryakov
Comment 8 2012-03-23 08:50:52 PDT
>And class names are case-sensitive. Like this? <style> .foo { color: green } </style> <p class="FOO">It's green in WebKit and Mozilla</a>
Ms2ger (he/him; ⌚ UTC+1/+2)
Comment 9 2012-03-23 09:06:15 PDT
<!DOCTYPE html> <style> .foo { color: green } </style> <p class="FOO">It's black in WebKit, Mozilla and Opera</a>
Alexey Proskuryakov
Comment 10 2012-03-23 09:30:26 PDT
Looks like we now agree that "should be ASCII case-insensitive" is not the correct behavior.
Ms2ger (he/him; ⌚ UTC+1/+2)
Comment 11 2012-03-23 09:34:22 PDT
We don't. Look carefully, and test in standards mode.
Alexey Proskuryakov
Comment 12 2012-03-23 09:41:33 PDT
You do realize that your example shows case sensitive matching in standards mode, not ASCII case insensitive, don't you?
Ms2ger (he/him; ⌚ UTC+1/+2)
Comment 13 2012-03-23 09:45:05 PDT
You realize I pointed out your comment #8 didn't make sense?
Alexey Proskuryakov
Comment 14 2012-03-23 10:06:53 PDT
Neither quirks nor standards mode behaves in the way bug title says. Comment 8 demonstrates half of that, which should make sense to most. Is there anything constructive you want us to do via this bug, or is it all about snarky comments?
Simon Pieters (:zcorpan)
Comment 15 2016-01-22 05:29:22 PST
<!DOCTYPE html> <style> p { color:red } [data-Å] { color:green } [data-å] { color:green } </style> <p data-Å>This should be green. <p data-å>This should be green. This is a simple interop bug. Please fix. :-)
Ahmad Saleem
Comment 16 2022-07-24 11:35:27 PDT
From the URL test case - Safari 15.6 on macOS 12.5 is matching all other browsers (Chrome Canary 106 and Firefox Nightly 104) and similarly from the simple inter-op bug mentioned in Comment 15 (changed into JSFiddle - https://jsfiddle.net/wk7xsjc1/show), Safari matches with all other browsers. Is it something more needed here or since all browsers are matching, we can consider this as "RESOLVED CONFIGURATION CHANGED" (if it was fixed along the way)? Thanks!
Ryosuke Niwa
Comment 17 2022-07-24 13:43:01 PDT
I'm sure we fixed this a long time ago.
Note You need to log in before you can comment on or make changes to this bug.