[whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
ian at hixie.ch
Wed Sep 5 13:47:07 PDT 2012
On Fri, 13 Jul 2012, Ryosuke Niwa wrote:
> On Fri, Jul 13, 2012 at 3:17 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 13 Jul 2012, Ryosuke Niwa wrote:
> > >
> > > *HTMLCollection* returns the first element.
> > This is for compat in the default case, I believe.
> > > *HTMLAllCollection* returns the first element or another
> > > HTMLAllCollection if there are multiple elements
> > This is needed for IE compat.
> We can't use live NodeList or a regular HTMLCollection?
I have no idea. I believe this matches IE, though, which makes sense for a
feature that exists only for IE compat (details below).
> > > *HTMLOptionsCollection* returns the first element or live NodeList
> > > if there are multiple elements
> > This is for compat, I believe. (We don't want to return just a node if
> > there are many matching.)
> We can't return HTMLAllCollection or RadioNodeList here?
RadioNodeList wouldn't make sense, they're not radio buttons.
HTMLAllCollection only exists for IE compat. So I don't see why we'd want
either here rather than NodeList or HTMLCollection.
> > > Can those 3 classes somehow return the same object? FWIW, WebKit has
> > > always returned a static node list.
> > WebKit doesn't support the microdata and radio button features,
> > presumably, and is presumably less than perfectly compatible with the
> > Web for the others. :-)
> I'm not certain if we're willing to change our behavior to match the
> spec. We haven't gotten any bug reports due to this behavior as far as I
> know, and following the spec introduces a significant code complexity.
At the end of the day, I'm happy to spec whatever the browsers converge
on. However, it seems Webkit is less than ideally compatible on several of
these things. For example:
Webkit returns undefined, whereas IE, Gecko, and Opera all return an
HTMLCollection. (IE returns an HTMLCollection with a tags() method, Gecko
and Opera do not. The spec requires an HTMLAllCollection, which is the
kind of collection that has a tags() method in the spec; in IE, all
collections have a tags() method, and document.all is actually a regular
HTMLCollection. We could change the spec here, e.g. to put tags() on all
collections or to just forget about tags() on the subcollection here.)
For HTMLOptionsElement, the situation is more murky.
>From what I can tell, IE doesn't do direct named access, you have to do it
via item() or namedItem(). The spec didn't support item() access for
names, though all the browsers did. I've filed a bug on DOM Core for that.
Using namedItem(), you see that IE returns a live HTMLCollection, the spec
returns a live NodeList, WebKit returns a static NodeList, and Opera and
Firefox return just the first option. (There's a note in the spec asking
if we should switch to HTMLCollection rather than NodeList.)
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg