Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Thu, 6 Sep 2012, Simon Pieters wrote: On Wed, 05 Sep 2012 22:47:07 +0200, Ian Hickson i...@hixie.ch wrote: 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.) I thought we had agreed to drop tags() everywhere except for the document.all collection. I guess the collection returned by document.all.foo wasn't discussed back then, though. Opera and Firefox don't support tags() there, which suggests it's not needed for compat, so maybe the spec should side with Opera/Firefox and return HTMLCollection instead of HTMLAllCollection. Ok, I've made document.all.foo return an HTMLCollection. On Thu, 6 Sep 2012, Ojan Vafai wrote: On Wed, Sep 5, 2012 at 1:47 PM, Ian Hickson i...@hixie.ch wrote: 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.) I haven't followed the details closely enough to know which APIs should be returning which types of lists/collections. As a general point though, anywhere we can avoid live NodeLists/Collections is a big improvement. They impose a significant implementation cost both in terms of complexity and in terms of performance impact. Ok, I've changed to match Opera and Firefox on this one, since that was the least complex solution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Wed, 05 Sep 2012 22:47:07 +0200, Ian Hickson i...@hixie.ch wrote: 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.) I thought we had agreed to drop tags() everywhere except for the document.all collection. I guess the collection returned by document.all.foo wasn't discussed back then, though. Opera and Firefox don't support tags() there, which suggests it's not needed for compat, so maybe the spec should side with Opera/Firefox and return HTMLCollection instead of HTMLAllCollection. -- Simon Pieters Opera Software
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Wed, Sep 5, 2012 at 1:47 PM, Ian Hickson i...@hixie.ch wrote: 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.) I haven't followed the details closely enough to know which APIs should be returning which types of lists/collections. As a general point though, anywhere we can avoid live NodeLists/Collections is a big improvement. They impose a significant implementation cost both in terms of complexity and in terms of performance impact.
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 i...@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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Fri, 13 Jul 2012, Ryosuke Niwa wrote: According to http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection *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. *HTMLFormControlsCollection* returns the first element or RadioNodeList if there are multiple elements This is needed to support the radio button value feature. *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.) *HTMLPropertiesCollection* returns PropertyNodeList This is to support the value features for microdata. 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. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Fri, Jul 13, 2012 at 3:17 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jul 2012, Ryosuke Niwa wrote: According to http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection *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? *HTMLFormControlsCollection* returns the first element or RadioNodeList if there are multiple elements This is needed to support the radio button value feature. *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? 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. - Ryosuke
