W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-70: Define the scope chain of onFoo events reference issue-1

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 14 Mar 2006 14:12:24 -0800
Message-Id: <9E010B2C-0C24-412E-B1C2-606E69B8453C@apple.com>
Cc: public-webapi@w3.org
To: Jim Ley <jim@jibbering.com>


On Mar 14, 2006, at 12:19 PM, Jim Ley wrote:

>
> "Maciej Stachowiak" <mjs@apple.com>
>> In DOM Level 2 Events, the order in which event listeners trigger  
>> was undefined. DOM Level 3 Events will specify an ordering, which  
>> is the order in which they are added.
>
> I'm not sure I see the motivation for this, it's not backwards  
> compatible, I cannot see it has any usecases - why not leave it an  
> undefined ordering?

I don't know what you mean by "not backwards compatible". Content  
can't possibly be relying on the ordering being undefined, so  
specifying the ordering can't break things. It is better for  
interoperability if the order is defined instead of arbitrary, code  
tested in one UA will be more likely to work in others.

> In fact I see many more use cases for being able to explicit set a  
> later defined event should be fired first, rather than forcing it  
> to last - e.g. so you can prevent all listeners you've not added  
> from responding.

That's an interesting idea but clearly requires the ordering to be  
defined, and requires a new mechanism to add an earlier event  
listener. Maybe something that could be looked at post DOM Level 3  
Events.

>
>>  so the Firefox order would compl with the new spec.
>
> so should foo.onclick fire before or after foo.setAttribute 
> ('onclick',... ) ?   :-)

Only one of them will fire, and whichever is set last wins. There's  
no need to define relative ordering since you can't have both at the  
same time.

Regards,
Maciej
Received on Tuesday, 14 March 2006 22:12:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:53 GMT