This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html Multipage: http://www.whatwg.org/C#case-sensitivity Complete: http://www.whatwg.org/c#case-sensitivity Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Element tag name matching should not be fully case insensitive Posted from: 173.48.23.63 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:28.0) Gecko/20100101 Firefox/28.0
I thought we had reached consensus that what we want is for HTML elements in HTML documents to compare the ascii-lowercased selector to the localName of the element and for others to just compare to the localName, both compares being case-sensitive. That way you can use interned strings in selector matching for better performance. But the spec text doesn't seem to reflect that. A testcase is at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2623 and shows green text in Blink, Gecko, and Presto. It shows red in Trident, but Trident has an incorrect localName ("div" instead of "DIV") in this case.
I don't recall such a decision, but it seems reasonable, if somewhat unintuitive. Done for element names (see checkin below). It looks like the same applies to attribute names; should I do that too? http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2623
Oops, wrong link, sorry: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2624
Yeah, I think attribute names should work similarly.
And thank you!
Ok, the attribute selector equivalent text is a bit convoluted, so don't hesitate to reopen the bug if I screwed it up some how.
Checked in as WHATWG revision r8261. Check-in comment: Match reality better in terms of selector case-sensitivity for attributes as well http://html5.org/tools/web-apps-tracker?from=8260&to=8261
seems reasonable at first glance.