This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23620 - [Shadow]: remove getElement* methods
Summary: [Shadow]: remove getElement* methods
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 16904 (view as bug list)
Depends on:
Blocks: 22716
  Show dependency tree / graph
 
Reported: 2013-10-24 08:57 UTC by Anne
Modified: 2014-12-15 07:16 UTC (History)
2 users (show)

See Also:

Attachments

Description Anne 2013-10-24 08:57:24 UTC 
I thought we agreed that if we add these they'll be on Element. Given the discussion on the WHATWG list, it seems unlikely anything but getElementById() will be added there. In any event, adding these on the subclass is not the way to settle this debate.
Comment 1 Dimitri Glazkov 2013-10-24 19:53:15 UTC 
I think that's fine. I duped the previous bug on this to 22515, but that got WONTFIX'd and lost.
Comment 2 Hayato Ito 2014-11-19 04:53:34 UTC 
*** Bug 16904 has been marked as a duplicate of this bug. ***
Comment 3 Philip Jägenstedt 2014-12-11 20:23:38 UTC 
The WHATWG discussion linked from bug 22515:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0207.html

Dimitri, are you still on board with this removal in spec and Blink?

I came here from bug 27569 where I suggested what looks like a simplification from the current state in Blink, by moving getElementsBy* (not getElementById) up from Document, Element and ShadowRoot to ParentNode, causing them to appear on DocumentFragment also.

The WHATWG thread amounts to "HTMLCollection is live and a PITA to implement". That's true, but it's already impossible to get rid of and implemented on ContainerNode in Blink, which makes it free to support for DocumentFragment.

I'm happy to go either way here, but if it's going to be removal it's best to do it before people start to depend on ShadowRoot.getElementsBy*.
Comment 4 Philip Jägenstedt 2014-12-11 20:30:20 UTC 
I enjoyed this:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0133.html
Comment 5 Dimitri Glazkov 2014-12-11 21:00:44 UTC 
This is a no-op refactoring for the developer, right? We're moving getElementBy* up in prototype chain.
Comment 6 Philip Jägenstedt 2014-12-11 21:09:40 UTC 
IIUC, Anne wants to remove getElementsBy* from ShadowRoot, meaning it could break stuff.

My suggestion in bug 27569 is to move things up to the ParentNode interface, which would result in getElementsBy* becoming available on non-ShadowRoot DocumentFragment as well.
Comment 7 Dimitri Glazkov 2014-12-11 22:57:49 UTC 
(In reply to Philip Jägenstedt from comment #6)
> IIUC, Anne wants to remove getElementsBy* from ShadowRoot, meaning it could
> break stuff.

That seems bad.

> My suggestion in bug 27569 is to move things up to the ParentNode interface,
> which would result in getElementsBy* becoming available on non-ShadowRoot
> DocumentFragment as well.

Yes, let's do this one.
Comment 8 Anne 2014-12-12 09:12:54 UTC 
I don't understand why it has taken so long to fix this that it is now deemed a compatibility risk. Which seems somewhat spurious given that there's only one implementation.
Comment 9 Philip Jägenstedt 2014-12-12 09:40:47 UTC 
I don't know if there's any compat risk in removing getElementsBy* from ShadowRoot in Blink, we could find out with use counters if removal seems like a worthwhile thing to aim for.

The bit I'm missing is why we should try to remove getElementsBy* from ShadowRoot and keep them away from DocumentFragment. It plainly seems cleaner spec- and implementation-wise to have them ParentNode. A request to have them on DocumentFragment is what started the WHATWG thread.

If other browsers would object to that I'm curious to know why. There's zero chance of getting rid of getElementsBy* from Document and Element, so there's no long-term potential for simplification that is being sacrificed.
Comment 10 Dimitri Glazkov 2014-12-12 20:18:19 UTC 
As discussed on bug 27569, I think it is okay to remove them. Hayato-san, can you put this into your queue?
Comment 11 Hayato Ito 2014-12-13 09:31:24 UTC 
Looks everyone agreed that we should remove this from the spec asap.

Let's me remove these from the spec in the next week.