Re: Event listener confusion

On Wed, 9 Apr 2008, Boris Zbarsky wrote:
> 
> 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?

Yup.

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

I've made that clearer. Please let me know if it's clear enough.


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

Yeah... the idea is that in JS the only way to provide an EventListener is 
to provide a Function. This is still a somewhat vaguely defined area, I'm 
mostly waiting for the DOM Bindings spec to stabilise so that I can define 
this more tightly.


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

Not sure what you mean here.


> The IDL should probably be clarified somewhat.

I agree. This will probably be clarified more when DOM Bindings is ready. 
If you have any suggestions on what I can do in the meantime, do let me 
know, though.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 10 April 2008 05:39:30 UTC