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

On 12/23/2011 08:13 PM, David Bruant 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
you mean eventtarget.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.

You can just add capturing event listener before <iframe> is added to 
document. For example


<html>
   <head>
   <script>
     document.addEventListener("load",
       function(e) {
         if (e.target == document.getElementById("ifr");) {
           ...
         }
       },
       true
     );
   </script>
   </head>
   <body>
     <iframe id="ifd" src="http://www.foobar.html"></iframe>
   </body>
</html>

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

Received on Friday, 23 December 2011 18:33:00 UTC