This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
This is a bug that should be fixed in implementations IMO.
This is something every implementation does, so practically speaking, the bug is in the spec.
Gecko doesn't.
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. https://zewt.org/~glenn/test-htmlcollection-item-strings.html
Adrian, can you tell us something about IE's behaviour here, or forward the question to the right person?
Adding Travis to look at this.
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.
I guess you can't share which sites this were?
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.
Travis, would you mind checking whether the breakage you observed on sites in IE9 was with document.all or with other HTMLCollections?
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) document.all.item('iframe') * IE7 = pass * IE8 = FAIL * IE9 = FAIL * Fx = pass * Ch = pass * Saf = pass * Op = pass document.anchors.item('anchor2') * 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
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.
From the results here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1384 http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Element-children.html https://zewt.org/~glenn/test-htmlcollection-item-strings.html it appears Chrome / Opera / Gecko consistently handle item(str) per spec, so I don't think we should change the spec.