Bug 15201 - HTMLCollection.item(string) should act like namedItem(string)
Summary: HTMLCollection.item(string) should act like namedItem(string)
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2011-12-15 02:36 UTC by Glenn Maynard
Modified: 2012-03-12 18:13 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Glenn Maynard 2011-12-15 02:36:30 UTC
HTMLCollection.item(string) behaves like HTMLCollection.namedItem(string) in most cases.  (Two exceptions are O11.60 and IE9, only when multiple matches are found; see bug #15200.)  This should probably be specified.

Test at https://zewt.org/~glenn/test-htmlcollection.html; results at https://zewt.org/~glenn/test-htmlcollection-results.html.
Comment 1 Ms2ger 2011-12-15 17:50:29 UTC
This is a bug that should be fixed in implementations IMO.
Comment 2 Glenn Maynard 2011-12-15 18:24:38 UTC
This is something every implementation does, so practically speaking, the bug is in the spec.
Comment 3 Ms2ger 2011-12-15 18:33:36 UTC
Gecko doesn't.
Comment 4 Glenn Maynard 2011-12-15 19:18:31 UTC
It looks like the usual evil IDL casting confusing things.  Re-testing, the browsers with this behavior are IE6, IE7, IE9 and Chrome (WebKit untested).  It's less clear-cut, but the fact that IE8 appeared to have fixed this but it was reverted in IE9 makes me suspect the change broke pages.

Comment 5 Ms2ger 2011-12-15 19:22:49 UTC
Adrian, can you tell us something about IE's behaviour here, or forward the question to the right person?
Comment 6 Adrian Bateman [MSFT] 2011-12-15 22:15:05 UTC
Adding Travis to look at this.
Comment 7 Travis Leithead [MSFT] 2011-12-15 23:30:26 UTC
Yep, it broke real pages.

In early IE9, we implemented the strict spec behavior. However, when several high-profile sites broke, we decided to just point the API implementation back to the IE7 code (not enough sites were using IE8 mode for this problem to manifest).

It's possible that as sites drop their IE-only code paths, that we'll be able to "fix" our implementation, but we have no plans to do so at the moment.
Comment 8 Ms2ger 2011-12-16 13:53:45 UTC
I guess you can't share which sites this were?
Comment 9 Boris Zbarsky 2011-12-16 16:34:32 UTC
The only reason WebKit does this is to make document.all.item(string) work, because it uses the same code for document.all and other HTMLCollections, fwiw.

We (Gecko) have gotten no bug reports about this breaking pages, to my knowledge.  I can't speak for Opera.
Comment 10 Boris Zbarsky 2011-12-16 16:35:47 UTC
Travis, would you mind checking whether the breakage you observed on sites in IE9 was with document.all or with other HTMLCollections?
Comment 11 Travis Leithead [MSFT] 2011-12-16 19:07:11 UTC
It was document.all related.

We use HTMLCollection for document.all and other collections like document.anchors.

After we "fixed" item() to work like Firefox (as of 2 years ago), the problem was that:
document.all.item('foo') no longer found an element with id="foo" in the document. Instead, the string 'foo' was coerced into a number (0) and used as an index-lookup, returning the HTMLHtmlElement...

It turns out that trying to make the change at that time was a bad idea, as our old interop report shows:

(pass means that item() will lookup by string name--not index alone)

* IE7 = pass
* IE8 = FAIL
* IE9 = FAIL
* Fx  = pass
* Ch  = pass
* Saf = pass
* Op  = pass

* IE7 = pass
* IE8 = FAIL
* IE9 = FAIL
* Fx  = FAIL (same as IE8 standards mode)
* Ch  = pass
* Saf = pass
* Op  = pass

I just re-checked the test with the current release of each Browser (results are the same except that IE9 was "fixed" and Opera factored their HTMLCollection out from their HTMLAllCollection:

Browser   document.all.item()  document.anchors.item()
========  ===================  =======================
IE9       pass                 pass
Firefox   pass                 FAIL 
Chrome    pass                 pass
Safari    pass                 pass
Opera     pass                 FAIL
Comment 12 Boris Zbarsky 2011-12-16 19:49:07 UTC
OK, that makes sense.  I absolutely agree that document.all needs to do the weird string thing for web compat; that's bug 15184.  I'm just not convinced that needs to extend to all HTMLCollections.
Comment 13 Ms2ger 2012-03-12 18:13:40 UTC
From the results here:


it appears Chrome / Opera / Gecko consistently handle item(str) per spec, so I don't think we should change the spec.