Bug 78909 - getElement* should return HTMLCollection
: getElement* should return HTMLCollection
Status: NEW
: WebKit
HTML DOM
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Enhancement
Assigned To:
:
:
: 101311 102843 102886 102983 103085 103096 103197 103364 104244
:
  Show dependency treegraph
 
Reported: 2012-02-17 09:43 PST by
Modified: 2013-04-24 10:45 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-02-17 09:43:34 PST
DOM level 4 spec has been updated per compat. issues. We should follow.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15609
------- Comment #1 From 2012-02-20 13:38:44 PST -------
Would it make sense to have HTMLCollection use dynamic node lists and fold the getElement* stuff into the CollectionType management?

I haven't looked in too much detail, but it seems the caching of the nodelists could be moved out of the node into the htmlcollection, leaving the node just having to deal with a few collections.

It looks like a big change though, i guess a first step might be to have HTMLCollection return a dynamic node list for named items, which would be a requirement for this bug anyway (and would fix a bunch of other places that are returning static node lists currently, like bug 9508, which is how i eventually found my way here in the first place :P).

I can probably spend some time on this if it's deemed worthwhile.
------- Comment #2 From 2012-02-20 15:16:44 PST -------
(In reply to comment #1)
> Would it make sense to have HTMLCollection use dynamic node lists and fold the getElement* stuff into the CollectionType management?

Sure.

> I haven't looked in too much detail, but it seems the caching of the nodelists could be moved out of the node into the htmlcollection, leaving the node just having to deal with a few collections.

No, that'll result in some perf. regression. HTMLCollection currently checks DOMVersion to invalidate the cache in length() but this results in bugs like https://bugs.webkit.org/show_bug.cgi?id=76003.

Instead, we'll need to re-use nodelist's infrastructure to invalidate node lists at node removal / insertion.

> It looks like a big change though, i guess a first step might be to have HTMLCollection return a dynamic node list for named items, which would be a requirement for this bug anyway (and would fix a bunch of other places that are returning static node lists currently, like bug 9508, which is how i eventually found my way here in the first place :P).

I don't really get what you mean by this. HTMLCollection can't be a DynamicNodeList sine DynamicNodeList is a NodeList: http://www.w3.org/TR/html5/common-dom-interfaces.html#htmlcollection-0
------- Comment #3 From 2012-02-20 15:59:30 PST -------
What i meant was that the implementations of DynamicNodeList and HTMLCollection look very similar, and perhaps they could both be folded into some common code, or have HTMLCollection be built on top of DynamicNodeList, or something of the sorts.

(In reply to comment #2)
> (In reply to comment #1)
> > It looks like a big change though, i guess a first step might be to have HTMLCollection return a dynamic node list for named items, which would be a requirement for this bug anyway (and would fix a bunch of other places that are returning static node lists currently, like bug 9508, which is how i eventually found my way here in the first place :P).
> 
> I don't really get what you mean by this. HTMLCollection can't be a DynamicNodeList sine DynamicNodeList is a NodeList: http://www.w3.org/TR/html5/common-dom-interfaces.html#htmlcollection-0

I was talking about making HTMLCollection::namedItems() return a dynamic node list instead of a static vector of nodes, but i got confused with another bug i was looking at, disregard this.
------- Comment #4 From 2012-02-20 16:05:58 PST -------
(In reply to comment #3)
> What i meant was that the implementations of DynamicNodeList and HTMLCollection look very similar, and perhaps they could both be folded into some common code, or have HTMLCollection be built on top of DynamicNodeList, or something of the sorts.

Yeah, that sounds like a worthwhile refactoring of its own.
------- Comment #5 From 2013-04-24 06:17:51 PST -------
rniwa: All the blocking bugs are fixed. What remains to fix this one?
------- Comment #6 From 2013-04-24 10:45:19 PST -------
(In reply to comment #5)
> rniwa: All the blocking bugs are fixed. What remains to fix this one?

getElement* still returns NodeList, not HTMLCollection in their respective IDL files.