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

On Mar 14, 2006, at 2:21 PM, 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)

That's not backwards compatibility, backwards compat for a spec means  
authoring to the lower version still works in the higher version. No  
spec attempts to guarantee forward compatibility except possibly via  
fallback mechanisms that cause future features to be ignored.

So I don't think this is a valid concern.

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

Here's a use case: I want to set an event handler from one subsystem  
that sets up some state that I'd like all future added event handlers  
to see. It doesn't seem terribly compelling but the cost is low.

>> That's an interesting idea but clearly requires the ordering to be  
>> defined
>
> Certainly, however I don't see anything else that does, so without  
> that, there's no need.

I disagree. Leaving the ordering unspecified will likely result in  
content accidentally depending on the ordering of whatever UA it is  
tested in. It's better to make the ordering consistent since UAs have  
no valid reason to be different.

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

Which current implementations will let you have separate <foo  
onclick=""> and foo.onclick handlers and fire both?

> and there's nothing in any current specification that disallows this.

There's nothing in any current specification about any of this stuff.  
That's why we are trying to specify it.

Regards,
Maciej

Received on Wednesday, 15 March 2006 21:23:15 UTC