[dom] Should the return values of getElementsByClassName/TagName/TagNameNS be HTMLCollection

The current IDL says that these return NodeList.  We have people who'd 
like to align Gecko with that, but I have a slight concern about it.  In 
particular:

1)  Gecko has returned HTMLCollections from these methods for a long time.
2)  IE returns HTMLCollections from these methods.
3)  Opera returns NodeLists from these methods, but Opera has a 
namedItem method on NodeList.prototype

So scripts that just use namedItem() on these objects work in every UA 
except the WebKit-based ones at the moment.  This makes me worry about 
web compat issues if we stop having a namedItem on these return values 
in Gecko.

Is there a reason these return values are not HTMLCollection, other than 
historical reasons dating back to when HTMLCollection wasn't in core DOM?

As far as I can see, the pros of changing the return type here are:

1)  These lists are already restricted to only elements, so there's no 
obvious problem with using an HTMLCollection.
2)  The changes would involve adding a method in WebKit and not removing 
any in any other browsers, so should have good web compat.
3)  Gives authors more tools to use on these return values.

The cons I see are:

1)  More work for WebKit, which was arguably just following the spec.
2)  Existing code that only decorates NodeList.prototype but not 
HTMLCollection.prototype with something would no longer work for these 
return values in WebKit or Presto (it already doesn't work in Trident or 
Gecko).  It's possible that we could ameliorate this by making 
HTMLCollection inherit from NodeList, I guess.

Any other obvious pros or cons?

Another option, of course, is to add namedItem to NodeList.  But then we 
have to wonder why we have the two different interfaces in the first 
place...

-Boris

Received on Tuesday, 17 January 2012 06:26:15 UTC