This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When HTMLCollection methods which take a string as an argument have multiple matches, most implementations return an array-like object. Although this can only happen with a nonconforming DOM, the spec should reflect this. Implementations are mixed between NodeList and HTMLCollection, but all tested browsers return an array of some kind (with a couple strange exceptions) except for Firefox, which always returns a single item. (To be clear, no change should be made for when a single result is returned.) Test at https://zewt.org/~glenn/test-htmlcollection.html; results at https://zewt.org/~glenn/test-htmlcollection-results.html.
What Firefox is doing here is actually following the DOM3 spec. Are there pages that actually depend on this behavior for things other than form.elements and document.all (which are vanilla HTMLCollections in some browsers, but not in Firefox or in the current spec)? If not, then it may make more sense to fix HTMLCollection implementations in other browsers by removing the document.all/form.elements hackery from it.
> Although this can only happen with a nonconforming DOM (Scratch that, since duplicate @name attributes aren't nonconforming, though this also happens with nonconforming duplicate @ids, which is what I was testing with.) (In reply to comment #1) > What Firefox is doing here is actually following the DOM3 spec. But if the spec disagrees with most implementations, it seems like the spec that's wrong. I don't have any data on whether this behavior is actively used, but being so close to interop it would seem a waste to push in the opposite direction. IE8 changing this for *only* namedItem was bizarre and unfortunate (https://zewt.org/~glenn/test-htmlcollection-results.html). coll.namedItem(string) and coll[string] doing different things is so much worse...
> but being so close to interop It depends. It's strictly easier to switch to returning only one element (almost certainly removes code in the process) than to switch to returning multiple elements (adds code). I can see making the latter change to Gecko if it's really needed for web compat, I guess, but otherwise it seems better to simplify the web platform instead of complicating implementations.
It's not really removing code if it still needs to be supported for HTMLAllCollection, though. (This would just move HTMLAllCollection's namedItem behavior into HTMLCollection, and HTMLAllCollection would drop the overload.) If NodeList was returned instead of HTMLCollection, then s/HTMLAllCollection/HTMLOptionsCollection/.
HTMLAllCollection has a whole bunch of other differences from HTMLCollection in any case (certainly in Gecko and Presto). I'm not sure that converging them is actually better than just admitting that they're totally different.
And in particular, requiring the document.all behavior from all HTMLCollections precludes certain implementation strategies that are otherwise beneficial, imo.
Not to suggest that they should be converged in general, just that the code for this case is needed anyway. Given that "children['string']" appears to be the same in every (tested) browser except Firefox it seems a clear way to go, but if browsers are all willing to change in the other direction (and it's not going to end up changed in just one or two other browsers, which would only compound the mess), I'm happy either way.
Chrome seems to match Firefox now.