- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 17 Jan 2012 01:24:56 -0500
- To: www-dom@w3.org
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