Bug 15200 - HTMLCollection string methods should return multiple matches
Summary: HTMLCollection string methods should return multiple matches
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 20225
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-15 02:35 UTC by Glenn Maynard
Modified: 2013-07-10 13:47 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Glenn Maynard 2011-12-15 02:35:06 UTC
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.
Comment 1 Boris Zbarsky 2011-12-16 16:32:22 UTC
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.
Comment 2 Glenn Maynard 2011-12-16 17:37:17 UTC
> 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...
Comment 3 Boris Zbarsky 2011-12-16 17:53:05 UTC
> 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.
Comment 4 Glenn Maynard 2011-12-16 18:21:54 UTC
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/.
Comment 5 Boris Zbarsky 2011-12-16 19:50:14 UTC
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.
Comment 6 Boris Zbarsky 2011-12-16 19:50:57 UTC
And in particular, requiring the document.all behavior from all HTMLCollections precludes certain implementation strategies that are otherwise beneficial, imo.
Comment 7 Glenn Maynard 2011-12-16 20:03:57 UTC
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.
Comment 8 Anne 2013-05-21 04:33:04 UTC
Chrome seems to match Firefox now.