27569 2014-12-11 14:59:32 +0000 Move getElementsBy* to ParentNode? 2014-12-13 19:36:57 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC Linux RESOLVED WONTFIX P2 normal --- 1 philipj annevk crimsteam dglazkov mike www-dom public-webapps-bugzilla oldest_to_newest 116144 0 philipj 2014-12-11 14:59:32 +0000 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. 116145 1 annevk 2014-12-11 15:23:10 +0000 See bug 23860 :-( 116146 2 philipj 2014-12-11 15:24:25 +0000 Sorry, I did read about that before filing, I mean NonElementParentNode. 116147 3 philipj 2014-12-11 15:25:50 +0000 Trying again. The problem is with Element.getElementById(). getElementsBy* is already on Element. Putting these on ParentNode should only affect non-ShadowRoot DocumentFragments. 116149 4 crimsteam 2014-12-11 15:32:13 +0000 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? 116151 5 annevk 2014-12-11 15:55:09 +0000 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. 116164 6 philipj 2014-12-11 19:43:17 +0000 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. 116165 7 annevk 2014-12-11 19:57:36 +0000 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? 116167 8 philipj 2014-12-11 20:10:38 +0000 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. 116202 9 philipj 2014-12-12 08:52:42 +0000 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? 116221 10 dglazkov 2014-12-12 16:04:31 +0000 (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*. 116234 11 philipj 2014-12-12 19:47:05 +0000 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. 116269 12 philipj 2014-12-13 19:36:57 +0000 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.