Currently WebKit treats Selectors as Unicode case-insensitive, just like the HTML parser they should be ASCII case-insensitive.
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.
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.
So "AAA" is case insensitive and "ААА" is case sensitive? Does this make any sense outside of spec writing universe?
You are making an appeal to logic. You must be new to the HTML parser.
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).
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.
I included a link. And class names are case-sensitive.
>And class names are case-sensitive. Like this? <style> .foo { color: green } </style> <p class="FOO">It's green in WebKit and Mozilla</a>
<!DOCTYPE html> <style> .foo { color: green } </style> <p class="FOO">It's black in WebKit, Mozilla and Opera</a>
Looks like we now agree that "should be ASCII case-insensitive" is not the correct behavior.
We don't. Look carefully, and test in standards mode.
You do realize that your example shows case sensitive matching in standards mode, not ASCII case insensitive, don't you?
You realize I pointed out your comment #8 didn't make sense?
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?
<!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. :-)
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!
I'm sure we fixed this a long time ago.