This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dom.spec.whatwg.org/#concept-id [[ unique identifier (ID) ]] HTML says [[ The unique identifier of HTML elements in documents that are in quirks mode must be treated as ASCII case-insensitive for the purposes of selector matching. Classes from the class attribute of HTML elements in documents that are in quirks mode must be treated as ASCII case-insensitive for the purposes of selector matching. ]] http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#case-sensitivity But this should apply to all elements. It applies to SVG too in browsers and also elements in unknown namespace (in Blink at least, Gecko appears to not support selecting such elements with id selector). Since it applies to all elements it might be good to move to DOM (or be directly in Selectors?). http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2627 (control) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2628
This only applies to CSS matching, right? For example, getElementById() still does case-sensitive matching I believe. Where to spec this is unclear. Maybe the right place is the quirks mode spec, even.
So either Selectors fully embraces defining matching in terms of the DOM or it keeps doing its somewhat-DOM-somewhat-abstract dance that's leaky as hell or it makes it fully abstract and then I guess DOM should define DOM-to-abstract.
Reassigning to see what Tab thinks.
Since we decided on a previous issue to keep CSS quirks in the quirks mode spec, I guess we should do the same for this, too.
Why did you decide that? The quirks mode specification should disappear.
Selectors isn't CSS, ba-dum-tsh
So is the HTML spec wrong here? Or? (This bug isn't assigned to me right now; please do reassign it to me if I should be fixing HTML.)
I think this is a bug in Selectors, unless we really want to override Selectors from Quirks Mode, which seems weird and hard to figure out when implementing, but okay.
I've specified it in quirks mode for now. http://quirks.spec.whatwg.org/#the-case-insensitive-class-and-id-selectors-quirk Hixie, you can drop the part quoted in comment 0 from HTML.
(But also fix the "everything else" paragraph and maybe point to the quirks spec)
Why is it better to have it in quirks than in HTML? Aren't we trying to drive the quirks spec to empty and move everything into other specs?
On the DOM side, yes. Our friends in the CSSWG don't seem inclined that way, though.
I'm happy to take care of the CSS stuff that only affects HTML. Does this affect more than HTML? ("Quirks mode" is only possible in text/html, right?)
You can have SVG nodes in HTML and it affects them. Or you can have a document that's in quirks mode and pour nodes in it from another document. We made quirks mode a DOM affair, it seems weird for selector matching of DOM to be an HTML affair.
Shouldn't it be in DOM then? My concern is that the quirks spec is essentially an "errata" spec and that most people won't read it. We need this kind of thing to be immediately visible to implementors.
(it really _should_ just be in the selectors spec, of course)
http://krijnhoetmer.nl/irc-logs/whatwg/20140506#l-5
(In reply to Anne from comment #17) > http://krijnhoetmer.nl/irc-logs/whatwg/20140506#l-5 It's in Selectors now: http://dev.w3.org/csswg/selectors/#data-model (look at the end of the section)
Cool. (Probably needs a reference to define "quirks mode", BTW, lest people wonder if "limited quirks" mode counts as "quirks mode" here.) zcorpan, is this all resolved now?
Checked in as WHATWG revision r8610. Check-in comment: The quirky class/id selector matching case logic moved to selectors http://html5.org/tools/web-apps-tracker?from=8609&to=8610
Yep. Thanks! https://github.com/whatwg/quirks/commit/cfda1c1f6d689072118b8e6a9a023f268d3c76be