Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?

On Fri, 13 Jul 2012, Ryosuke Niwa wrote:
> On Fri, Jul 13, 2012 at 3:17 PM, Ian Hickson <ian@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:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1736

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.

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1739

>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.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 5 September 2012 20:47:34 UTC