W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

[Events] A case where on* attributes are required

From: David Bruant <david.bruant@labri.fr>
Date: Fri, 23 Dec 2011 19:13:31 +0100
Message-ID: <4EF4C4CB.1000304@labri.fr>
To: www-dom@w3.org
CC: Boris Zbarsky <bzbarsky@MIT.EDU>

A couple of tweets and a private e-mail conversation with Boris Zbarsky
led to the conclusion that some event handlers can't be expressed with
event.addEventListener and require inline on* attributes. I'd like to
raise this concern here.

Currently, if one wants to know when an iframe was loaded, she has to
set an inline @onload attribute: <iframe onload="doSomething()">
Several aspects contribute to the necessity of this attribute. First,
the event has to be fired synchronously. Second, this happens while HTML
parsing is ongoing, so the HTMLIframeElement is created while parsing.
These two combined make that the event may need to be fired before any
script has the opportunity to use the HTMLIframeElement reference can be
attached a 'load' event listener.

This issue applies to 'load' and 'error' events of pretty much all
elements that load something (img, audio, video, link, etc.).

I say that it's an issue, because it gets on the way to separation of
concerns (HTML for content/structure, CSS for style and JS for
behavior), since it requires to put some JavaScript inlined in HTML.

I have raised the issue and would like to know whether other people
consider the raised issue to be one. The second part of this e-mail is
an attempt to solve this problem, but this attempt should be replied to
separately (or ignored completely if it's inadequate).


I do not have a good proposal for now. One issue is that unlike usual
event listener binding (with .addEventListener), you cannot have a
reference to the element you want to bind a listener to. Indeed, the
HTML is being parsed and yet, the event could be fired before you have
the occasion to attach a listener to the 'load' event.

One idea could be to have an API like:
document.addEventListener(cssSelector + '@' + 'load', listener);
document.addEventListener(cssSelector + '@' + 'error', listener);

The CSS selector is here to match the element we want to attach a
listener to. The listener is attached to the document since that's the
thing that is being constructed during HTML parsing.
It would work like this:
document.addEventListener('iframe@error', listener);
=> attach the 'listener' listener to error events of all iframes. So
each time an error event is fired on an iframe, it would synchronously
cal the 'listener' listener.

It's not a very sexy API and is really just here to give an example of
how it would work. I have no strong attachements to this proposal, but
I'm convinced the problem described above should be addressed.


Received on Friday, 23 December 2011 18:14:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:18 UTC