- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 17 Feb 2012 16:45:23 +0100
- To: "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: www-dom@w3.org
On Fri, 17 Feb 2012 16:26:07 +0100, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 2/17/12 10:16 AM, Anne van Kesteren wrote: >> Do we want to keep NodeList around or is NodeList going away in favor of >> HTMLCollection? E.g. what should Node.childNodes return? > > That's a good question. > > There's a fundamental difference between Node.childNodes and the > getElement* methods: the latter end up with a list of Elements only, > while the former can contain other Node objects. If the latter became > an HTMLCollection, then the HTMLCollection IDL would need to change from > Element to Node for the various return values, right? This may not be > an issue in practice, I guess, especially in JS. And of course we'd > need to change the definitions of namedItem and such very slightly so > they make sense for lists that might contain non-elements. > > I guess I don't have a strong opinion either way. Implementation-wise, > childNodes is implemented in a completely different way from the other > lists in Gecko, so changing it would require additional work, but > probably not a huge amount... Having a collection of nodes is also useful for mutation observers so keeping element and node collections somewhat distinct is probably okay. We could make HTMLCollection inherit from NodeList as you suggested, but I'm not sure whether that's worth it. I will make the change meanwhile of changing all these three methods to return HTMLCollection. That seems the most sensible given the data you gave. -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 17 February 2012 15:45:57 UTC