Bug 81752
| Summary: | Selectors should be ASCII case-insensitive in HTML | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Anne van Kesteren <annevk> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Normal | CC: | ahmad.saleem792, ap, bfulgham, ian, Ms2ger, rniwa, simon.fraser, tabatkins, zalan, zcorpan |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1307 | ||
Anne van Kesteren
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
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
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
So "AAA" is case insensitive and "ААА" is case sensitive? Does this make any sense outside of spec writing universe?
Tab Atkins
You are making an appeal to logic. You must be new to the HTML parser.
Ian 'Hixie' Hickson
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
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
I included a link. And class names are case-sensitive.
Alexey Proskuryakov
>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)
<!DOCTYPE html>
<style> .foo { color: green } </style>
<p class="FOO">It's black in WebKit, Mozilla and Opera</a>
Alexey Proskuryakov
Looks like we now agree that "should be ASCII case-insensitive" is not the correct behavior.
Ms2ger (he/him; ⌚ UTC+1/+2)
We don't. Look carefully, and test in standards mode.
Alexey Proskuryakov
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)
You realize I pointed out your comment #8 didn't make sense?
Alexey Proskuryakov
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)
<!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
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
I'm sure we fixed this a long time ago.