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.

Note that the Gecko implementation will be assuming the spec is fixed as I suggest.

This bug was cloned to create bug 18195 as part of operation convergence.

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)?

(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?

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.

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.)

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.

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?

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.

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.

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

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?

(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.

https://github.com/whatwg/dom/commit/9ad090672d52b542818a528e2425eafa30c0721b

Reassigning to Ian to make HTML clearer as per comment 13 and comment 14.

Thanks.