W3C home > Mailing lists > Public > public-html@w3.org > April 2008

Event listener confusion

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 09 Apr 2008 23:36:20 -0500
Message-ID: <47FD9944.2090309@mit.edu>
To: "public-html@w3.org" <public-html@w3.org>

I'm trying to make sense of the text at 
<http://www.whatwg.org/specs/web-apps/current-work/#events>.  Specifically, 
let's look at the "onclick" event handler DOM attribute.

   Event handler DOM attributes, on setting, must set the corresponding
   event handler attribute to their new value, and on getting, must
   return whatever the current value of the corresponding event handler
   attribute is (possibly null).

I assume this doesn't mean the "event handler content attribute", right?  If I 
set document.body.onclick to some function, the corresponding "event handler 
attribute" attribute is now that function, correct?

Reading right along:

   When an event handler attribute is invoked, its argument must be set
   to the Event object of the event in question. If the function returns
   the exact boolean value false, the event's preventDefault() method
   must then invoked.

So if there is a click, my function will be called, and if the function returns 
false the event's preventDefault() will be called.  This all makes sense.

   When scripting is enabled, all event handler attributes on an element,
   whether set to null or to a function, must be registered as event
   listeners on the element, as if the addEventListenerNS() method on
   the Element object's EventTarget  interface had been invoked
   ....
   and the event listener itself (listener  argument) set to do nothing
   while the event handler attribute is null, and set to invoke the
   function associated with the event handler attribute otherwise.

I think what this is trying to say is that the "listener" argument should be a a 
synthesized EventListener whose handleEvent calls the "event handler attribute" 
function and then does the preventDefault thing above.  It would be good to make 
that clearer.  In particular, it should be made clear that the "listener" 
argument is NOT the "event handler attribute" attribute function.

The other issue I see here is in the IDL:

   attribute EventListener onclick;

But actually assigning an object that implements EventListener to the onclick 
DOM  property won't do the right thing.  The things that can be assigned here 
and affect the "event handler attribute" are really only Functions.  For 
example, in some UAs it's possible to assign a String to document.body.onclick, 
and it won't affect the click handlers for the body...  I'm not sure how much 
compat there is across UAs here.

The IDL should probably be clarified somewhat.

-Boris
Received on Thursday, 10 April 2008 04:37:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:54 UTC