Re: [Events] A case where on* attributes are required

There are a number of workarounds for this problem. Another way you could
address this specific problem is to check whether the iframe has already
loaded before running adding the load handler.

That said, all these other ways are a bit unnatural and require careful
coding. jQuery has an API for this (http://api.jquery.com/live/) that works
really nicely in my experience. In our case we might want something like
the following:
document.listen(selector, eventName, handler)

I'm a bit torn about this because the API is really convenient, but it also
has performance implications (i.e. when do you selector match to find which
elements care about which events). I'm having trouble thinking of a way to
implement this that doesn't either make DOM operations or event dispatch
slow.

We could limit the performance impact by restricting to simple selectors.
But that wouldn't completely address the performance issues and it would
limit a lot of useful things you can do with this API.

Maybe it's OK in practice to do selector matching when firing events that
fire infrequently (e.g. load, focus, etc) and to selector match at DOM
operation time for events that fire frequently (e.g. mousemove, keydown,
etc).

I'm curious what other browser developers think. Could this be done without
significant performance impact?

On Fri, Dec 23, 2011 at 1:13 PM, David Bruant <david.bruant@labri.fr> wrote:

> Hi,
>
> 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.
>
> Thanks,
>
> David
>
>