[whatwg] HTMLElement.onload

Sun Oct 25 15:45:35 PDT 2009

Simon Pieters schrieb:
> On Fri, 23 Oct 2009 17:16:13 +0300, Markus Ernst <derernst at gmx.ch> wrote:
> 
>> In 6.5.6.2 of the spec I found, that the onload event handler is now 
>> available for every HTML element in HTML5, which I think is a great 
>> improvement. But there is something on the load event, that I think 
>> would be worth some words to clarify.
>>
>> According to 6.11.2 the load event is fired when the whole document is 
>> loaded; I did not find anything about element-specific load events. So 
>> I assume that element1.onload is triggered by the same event as 
>> element2.onload - the following two bodies would be equivalent:
>>
>> <body>
>>    <p onload="dosomething(this)">Text</p>
>>    <p onload="dosomethingelse(this)">Text</p>
>> </body>
>>
>> <body onload="dosomething(document.getElementById('foo'));
>>    dosomethingelse(document.getElementById('bar'))">
>>    <p id="foo">Text</p>
>>    <p id="bar">Text</p>
>> </body>
>>
>> Is this assumption correct?
> 
> No. The first registers two listeners on two elements, and the second 
> registers one listener on the window. When the document loads, a load 
> event is fired on the window, but there's nothing that fires load events 
> on <p>, so for the first example to do anything you have to fire the 
> event yourself with script.
> 
> 
>> Generally, the list of events that must be supported by all HTML 
>> elements looks somehow confusing to me, as there are some events that 
>> only apply to special types of elements, such as media players or 
>> forms resp. form elements. How are e.g. onpause or oninput supposed to 
>> work if applied to span or p elements?
> 
> Same as onload -- it just registers a listener. pause and input events 
> don't bubble and don't fire on span or p unless you do it yourself with 
> script. Maybe it doesn't make any sense to have <p onpause>, but it's 
> easier to implement (which in turn means less bugs and thus less 
> headaches for authors) to support all event handlers everywhere.
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#events-0 
> (and the tables referenced from there) is useful for finding out which 
> events are fired where.

Thank you for making this clear.

The spec says in 3.2.3: "The following event handler content attributes 
may be specified on any HTML element" - with my quite trivial 
understanding, I would actually expect something to happen if I do this. 
The note "The attributes marked with an asterisk have a different 
meaning when specified on body elements as those elements expose event 
handlers of the Window object with the same names" does not correct this 
expectation, but rather implies, that onload on any element has an 
effect, as it is supposed to have another effect than when specified in 
the body element.

I understand that the spec is not a reference manual for authors, but as 
authors are actually encouraged to read the spec, I suggest to add 
another note to 3.2.3, saying something like: "Note: specifying an event 
handler content attribute on an element may have no effect, if the 
corresponding event is not fired at this element. If you are not sure 
which events are fired at which elements, refer to 
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#events-0."

Also, in this events table, the description of the load event is very 
rudimentary: "Fired when a resource has finished loading". I suggest 
changing this to something like: "Fired at the Window object when the 
document has finished loading, or at an element containing a resource, 
when the resource has finished loading".