81752 2012-03-21 03:36:08 -0700 Selectors should be ASCII case-insensitive in HTML 2022-07-24 13:43:01 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Unspecified Unspecified RESOLVED CONFIGURATION CHANGED http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1307 P2 Normal --- 1 annevk webkit-unassigned ahmad.saleem792 ap bfulgham ian Ms2ger rniwa simon.fraser tabatkins zalan zcorpan oldest_to_newest 583957 0 annevk 2012-03-21 03:36:08 -0700 Currently WebKit treats Selectors as Unicode case-insensitive, just like the HTML parser they should be ASCII case-insensitive. 584261 1 ap 2012-03-21 10:03:09 -0700 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. 584518 2 tabatkins 2012-03-21 12:49:09 -0700 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. 584620 3 ap 2012-03-21 14:07:53 -0700 So "AAA" is case insensitive and "ААА" is case sensitive? Does this make any sense outside of spec writing universe? 584655 4 tabatkins 2012-03-21 15:02:19 -0700 You are making an appeal to logic. You must be new to the HTML parser. 584665 5 ian 2012-03-21 15:08:52 -0700 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). 584706 6 ap 2012-03-21 15:36:53 -0700 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. 586169 7 annevk 2012-03-23 01:37:10 -0700 I included a link. And class names are case-sensitive. 586366 8 ap 2012-03-23 08:50:52 -0700 >And class names are case-sensitive. Like this? <style> .foo { color: green } </style> <p class="FOO">It's green in WebKit and Mozilla</a> 586379 9 Ms2ger 2012-03-23 09:06:15 -0700 <!DOCTYPE html> <style> .foo { color: green } </style> <p class="FOO">It's black in WebKit, Mozilla and Opera</a> 586404 10 ap 2012-03-23 09:30:26 -0700 Looks like we now agree that "should be ASCII case-insensitive" is not the correct behavior. 586419 11 Ms2ger 2012-03-23 09:34:22 -0700 We don't. Look carefully, and test in standards mode. 586431 12 ap 2012-03-23 09:41:33 -0700 You do realize that your example shows case sensitive matching in standards mode, not ASCII case insensitive, don't you? 586434 13 Ms2ger 2012-03-23 09:45:05 -0700 You realize I pointed out your comment #8 didn't make sense? 586448 14 ap 2012-03-23 10:06:53 -0700 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? 1157658 15 zcorpan 2016-01-22 05:29:22 -0800 <!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. :-) 1886385 16 ahmad.saleem792 2022-07-24 11:35:27 -0700 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! 1886403 17 rniwa 2022-07-24 13:43:01 -0700 I'm sure we fixed this a long time ago.