[whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for "body" elements

[Ian Hickson]

On Mon, 3 Dec 2012, Boris Zbarsky wrote:
> On 12/3/12 7:33 PM, Ian Hickson wrote:
> > Note that onerror has a different type on HTMLElement and 
> > HTMLBodyElement.
> 
> Yes, indeed.  That's the biggest problem with forwarding to Window for 
> the HTMLElement.prototype case for "onerror" here: the types are 
> different.
> 
> > onscroll is a case where there's really no reason to use a different 
> > setter, agreed. So I've commented that out (and it's similar friends). 
> > That still leaves onerror though.
> 
> Indeed.  I would have no problem with just having 
> HTMLElement.prototype.onerror's setter set an error handler on the body 
> itself, like it would on any other HTML element, and likewise for the 
> getter.
> 
> > Per our IRC discussion just now, I think I would propose that when a 
> > method/setter/getter from a prototype of interface A is called against 
> > an object that is of an interface B (or one of B's descendants), where 
> > B is a subclass of A, and B defines its own method/getter/setter with 
> > the same name, then it should throw.
> 
> Hmm.  That, as phrased, is pretty complicated to implement in a 
> performant way, if the two methods/getters/setters have the same 
> signatures...

heycam, did we resolve this at the WebIDL level by any chance? Or is this 
still open? (If the latter, is there a bug# for it? Or is this an HTML 
problem I need to fix myself?)


On Mon, 3 Dec 2012, Boris Zbarsky wrote:
> 
> I have to ask: are there languages or runtime systems that have that 
> sort of behavior on method calls (as opposed to in method 
> implementations in special cases where the operation is nonsensical)? It 
> seems weird to be requiring this behavior, in general.

Most languages, if you invoke the method of a superclass on an object of a 
subclass that overrides that method in an incompatible way, will just let 
you crash the application.

This isn't an option for us.

In practice there are only a few of these cases, so implementations 
_could_ special-case them, rather than doing it at the binding level. If 
you have actual IDL in your pipeline, the compiler could flag which cases 
need this, and automatically generate tests to make sure they are done. It 
doesn't have to be a widespread performance impact.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'