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: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 15 Mar 2006 05:43:08 -0800
Message-ID: <441819EC.8030605@sicking.cc>
To: Jim Ley <jim@jibbering.com>
Cc: public-webapi@w3.org

Jim Ley wrote:
> "Maciej Stachowiak" <mjs@apple.com>
>> 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.
> That is exactly what I mean by backwards compatibility, you're 
> introducing stricter requirements in later UA's meaning that authoring 
> to the spec breaks compatibility in DOM 2 implementations (because the 
> author can now _rely_ on a particular ordering, rather than having to 
> use the simple code methods to create an ordering)

Isn't that the case for every feature we are adding? That it means that 
code written for DOM Level 3 will not necessarily work in DOM Level 2. I 
don't see that as a problem. If it was I don't see the point in creating 
a Level 3 at all.

> Without use cases for requiring an order, it shouldn't be done. It 
> probably should've in 2, but wasn't presumably for reasons, what's 
> changed about the reasons then?

I agree with this, we should have usecases for features we add.

>>> 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.
> You can in some current implementations, and there's nothing in any 
> current specification that disallows this.

The spec we are writing now, as proposed, disallows this. Do you think 
that is a problem and will break existing content?

/ Jonas
Received on Wednesday, 15 March 2006 13:43:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC