17201 2012-05-25 23:23:42 +0000 HTMLCollection.prototype.namedItem behavior not defined for HTMLPropertiesCollection 2013-04-29 23:09:05 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#htmlpropertiescollection-0 P3 normal Unsorted 20225 1 contributor ian bzbarsky cam dzbarsky ian mike Ms2ger www-dom contributor oldest_to_newest 68172 0 contributor 2012-05-25 23:23:42 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html Multipage: http://www.whatwg.org/C#htmlpropertiescollection-0 Complete: http://www.whatwg.org/c#htmlpropertiescollection-0 Comment: HTMLCollection.prototype.namedItem behavior not defined for HTMLPropertiesCollection Posted from: 71.184.125.56 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/15.0 Firefox/15.0a1 68173 1 bzbarsky 2012-05-25 23:26:19 +0000 In particular, the spec for HTMLPropertiesCollection says: legacycaller getter PropertyNodeList? namedItem(DOMString name); // overrides inherited namedItem() But the "inherited" namedItem can still be applied to HTMLPropertiesCollection objects, and the behavior of that needs to be defined. HTMLCollection says in an informative note: The namedItem() method returns an object for interfaces that inherit from this interface, which return other objects for historical reasons. and the IDL is: getter object? namedItem(DOMString name); so what you probably want to do here is not override it at all and just say in normative prose that the object returned, if any, is a PropertyNodeList. 68175 2 bzbarsky 2012-05-25 23:29:36 +0000 Note that the Gecko implementation will be assuming the spec is fixed as I suggest. 70857 3 contributor 2012-07-18 17:38:16 +0000 This bug was cloned to create bug 18195 as part of operation convergence. 72781 4 ian 2012-08-26 03:11:50 +0000 heycam, can I get me some IDL love to describe this? An "override" keyword for example, whose semantic would be "the prose for this operation defines what the inherited operation does when applied to objects implementing this interface, overriding the superclass' definition", with the requirement that the signatures be identical or that the subclass' signature be a subset (as here)? 72872 5 cam 2012-08-27 23:46:37 +0000 (In reply to comment #4) > heycam, can I get me some IDL love to describe this? An "override" keyword for > example, whose semantic would be "the prose for this operation defines what the > inherited operation does when applied to objects implementing this interface, > overriding the superclass' definition", with the requirement that the > signatures be identical or that the subclass' signature be a subset (as here)? I'm confused. Do you want HTMLPropertiesCollection.prototype.namedItem to exist or not? If it should exist, how does its behaviour differ from HTMLCollection.prototype.namedItem called on the same object? 74319 6 ian 2012-09-23 01:09:06 +0000 heycam: I don't know, I just want to make bz happy... I think I want HTMLPropertiesCollection.prototype.namedItem to exist (and its behaviour to be as specced today), but the question is what does HTMLCollection.prototype.namedItem do when called on an HTMLPropertiesCollection? Or in general, what does a method do when it is defined on an interface that is the superclass of another interface that redefines that method to do something else (overrides it), but the superclass method is then invoked on the subclass? I'd be pretty much fine with any behaviour except "do what it is defined to do on the superclass" since that would require having to work out every combination of method called on any subclass of its interface that overrides that method, which could be easy to screw up. 79320 7 cam 2012-12-03 21:43:55 +0000 My suggested solution is: * Have the definition of HTMLCollection.namedItem include a hook that other specifications can override for descendant classes like HTMLPropertiesCollection. * Do that overriding for HTMLPropertiesCollection. * Not define a distinct namedItem on HTMLPropertiesCollection. I can see that if you did still include a namedItem on HTMLPropertiesCollection with its special behaviour, then you could save yourself effort by putting an extended attribute on HTMLCollection's one (which means "delegate to the subclass") but I don't think it's really necessary for IDL support there, or for HTMLPropertiesCollection.namedItem to exist in the first place. (If HTMLPropertiesCollection.namedItem did still exist, I would make it work only on HTMLPropertiesCollection objects, which would be the default behaviour anyway.) 81030 8 cam 2013-01-08 07:05:24 +0000 I just took another look at this. I actually don't see the problem with overriding namedItem like you do currently, and leaving the existing HTMLCollection.prototype.namedItem to work as it is described if you call HTMLCollection.prototype.namedItem.call(aPropertiesCollection, ...). The behaviour seems to be defined well enough. If you think this does not make sense, then I think HTMLPropertiesCollection should not be an HTMLCollection. Either of these will be simpler than defining a hook to define the behaviour for HTMLCollection.namedItem. If you do make HTMLPropertiesCollection not inherit from HTMLCollection, you could still have it be a "collection" in the sense of the term defined in the DOM spec. That would save some redefinition. The two members that you currently inherit -- item() and length -- are simple to define in prose given the current definitions of "collection" in the DOM spec. 81162 9 ian 2013-01-10 00:54:22 +0000 I guess if all the current combinations are well-defined, we can just be really careful not to introduce any ill-defined cases. bz: Do you agree with heycam that your original report is actually wrong and namedItem(), when taken from HTMLCollection but applied to HTMLPropertiesCollection, is actually well-defined after all? 81167 10 bzbarsky 2013-01-10 01:26:42 +0000 I think that's fine, but then we should just change HTMLCollection to return "Element?" for its namedItem, I suspect. At least if there are no other weird cases like this. 84092 11 ian 2013-03-07 23:10:34 +0000 Ok. I've changed the comments to say "shadows" instead of "overrides", since you can still get the parent ones. I'm reassigning this to Anne for the remaining DOM stuff. 84093 12 contributor 2013-03-07 23:14:39 +0000 Checked in as WHATWG revision r7739. Check-in comment: Change comment to be more precise. http://html5.org/tools/web-apps-tracker?from=7738&to=7739 84113 13 annevk 2013-03-08 10:15:15 +0000 I'm not sure what needs doing now. Should I change DOM's HTMLCollection "object?" to "Element?"? Is that it? Should HTML's HTMLAllCollection then change "object?" to "(Element or HTMLCollection)?" maybe? 84905 14 cam 2013-03-25 04:53:10 +0000 (In reply to comment #13) > I'm not sure what needs doing now. Should I change DOM's HTMLCollection > "object?" to "Element?"? Is that it? If HTMLCollection.prototype.namedItem only ever returns an Element or null even when applied to an HTMLAllCollection, which is how I understand it, then make it return "Element?". > Should HTML's HTMLAllCollection then change "object?" to "(Element or > HTMLCollection)?" maybe? Yes, the latter is a bit more descriptive. 84931 15 annevk 2013-03-25 17:16:49 +0000 https://github.com/whatwg/dom/commit/9ad090672d52b542818a528e2425eafa30c0721b Reassigning to Ian to make HTML clearer as per comment 13 and comment 14. 86969 16 ian 2013-04-29 23:09:05 +0000 Thanks.