getElement* should return HTMLCollection

• Component: DOM
• Status: RESOLVED DUPLICATE

[Ryosuke Niwa]

DOM level 4 spec has been updated per compat. issues. We should follow.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15609

[Pablo Flouret]

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.

[Ryosuke Niwa]

(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

[Pablo Flouret]

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.

[Ryosuke Niwa]

(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.

[Erik Arvidsson]

rniwa: All the blocking bugs are fixed. What remains to fix this one?

[Ryosuke Niwa]

(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.

[Chris Dumez]

*** This bug has been marked as a duplicate of bug 110611 ***