This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://dom.spec.whatwg.org/#interface-document In the spec getElementsByTagName, getElementsByTagNameNS and getElementsByClassName are on Document and Element separately. They're also on ShadowRoot, which inherits from DocumentFragment: http://w3c.github.io/webcomponents/spec/shadow/#shadowroot-object Putting it on ParentNode seems like a simplification, and that's also where querySelector and querySelectorAll live. The observable difference would be that getElementsBy* become usable on non-ShadowRoot DocumentFragments.
See bug 23860 :-(
Sorry, I did read about that before filing, I mean NonElementParentNode.
Trying again. The problem is with Element.getElementById(). getElementsBy* is already on Element. Putting these on ParentNode should only affect non-ShadowRoot DocumentFragments.
I proposed the same thing for the same reason some time ago to Anne (via email) but don't get any answer why not:), but happy that getElementById() was added and now we can use it in DocumentFragment. Summary I thought that is the reason: nobody want extend usage of old collection like HTMLCollection. But this change will be nice simplification for specs and using for newbie; still see a lot of questions why Document|DocumentFragment.getElementsBy* not work (the same was for getElementById()). Maybe now I can read reason why they can't be move to ParentNode. Of course moving to NonElementParentNode also looks good, maybe some days old jQuery disappear completely. But hmm: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23860#c4 BZ: [jQuery 1.2.5 assumes that any node it found in the DOM that has a "getElementById" property is a Document node. See https://bugzilla.mozilla.org/show_bug.cgi?id=933193#c17} so moving getElementsBy* to ParentNode will breake jQuery to?
So yeah the story is that getElementBy* methods that are not getElementById should not be added to more objects since we want developers to move away from them. Therefore there's an outstanding bug on shadow DOM to remove them from ShadowRoot. jQuery is only affected by getElementById as I understand it.
Where's the bug to remove getElementsBy* from ShadowRoot? Why do we want to avoid spreading getElementsBy* to DocumentFragment? At least in Blink it wouldn't add any complexity, it's already implementing in a base class shared by DocumentFragment and the others. The reason I filed this bug is in fact because it looks like a simplification, by having these defined in a single place in the IDL as well, instead of spread out in this odd fashion.
Bug 23620. It's a simplification to go from just Document and Element, to Document, DocumentFragment, and Element? That sounds odd. Are you sure that's not due to them existing on ShadowRoot at the moment?
Right, it would be a simplification to move it up from ShadowRoot to DocumentFragment and then to ParentNode as that would complete the Document-DocumentFragment-Element trio that implement ParentNode. If these are dropped from ShadowRoot then only Document and Element would remain and at best they could have a new common interface, but I'll comment on bug 23620 before speculating further.
In bug 23620 Dimitri isn't excited about dropping getElementsBy* from ShadowRoot. The path I would suggest is to move getElementsBy* to ParentNode and then remove them from ShadowRoot in specs and implementation. Other than discouraging use of live HTMLCollection, is there any reason to avoid exposing getElementsBy* on DocumentFragment?
(In reply to Philip Jägenstedt from comment #9) > In bug 23620 Dimitri isn't excited about dropping getElementsBy* from > ShadowRoot. > > The path I would suggest is to move getElementsBy* to ParentNode and then > remove them from ShadowRoot in specs and implementation. Other than > discouraging use of live HTMLCollection, is there any reason to avoid > exposing getElementsBy* on DocumentFragment? Oh crap. All this time I was reading "getElementsBy*" as "getElementById". Now that I am actually reading this correctly, I think we should go ahead with deprecating ShadowRoot.getElementsBy*.
OK, will you remove them from the spec as well? I'll send an Intent to Deprecate. Whether or not to have getElementsBy* on DocumentFragment is a separate matter, although my argument for simplicity becomes weaker with them gone from ShadowRoot.
I'm WONTFIXing this. With getElementsBy* being removed from ShadowRoot, the argument for simplification becomes much weaker, and I believe sticking to just Document and Element will allow us to reach interop faster.