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

On Mar 15, 2006, at 1:31 PM, Jim Ley wrote:

>
> "Maciej Stachowiak" <mjs@apple.com>
>> 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.
>
> I disagree, all well authored specs, particular in situations such  
> as web api's where there is no way to tell what version of an API  
> is in use (hasFeature is meaningless, and even if it wasn't there's  
> no way yo're doing something useful if you say hasFeature 2.0  
> returns false when 3.0 returns true.

If you feel strongly that it is important to distinguish when order  
of even dispatch is guaranteed, we could add a property to test for  
it. But if you think it doesn't have important use cases, then I  
don't see why it is important to tell when it is in effect.

>> So I don't think this is a valid concern.
>
> It's a a very big concern for content authors, we can't know what  
> environment we're running in, that means we will always be doing  
> the 2 behaviour, this makes the 3 behaviour irrelevant.

As far as I am concerned, it would be just fine for content authors  
to write their content as if order of event dispatch were undefined,  
but for UAs to still do dispatch in a consistent order for better  
interoperability in case the author accidentally depends on order.

Keep in mind that the spec is not just a contract between content  
authors and impementors, but also a contract between different  
implementations.

If it makes a promise that you, as a content author, would rather not  
rely on, then you are free to ignore it and I do not see the harm done.

>> I disagree. Leaving the ordering unspecified will likely result in  
>> content accidentally depending on the ordering of whatever UA it  
>> is tested in.
>
> I think you need to point to large amounts of code that does this,  
> ie it's a genuine problem, I do not believe it is.

I wouldn't know how to tell if there's code out there that could  
depend on order of event dispatch. My experience with large systems  
is that it's hard to avoid dependencies like this creeping in.

>
>>> You can in some current implementations,
>>
>> Which current implementations will let you have separate <foo   
>> onclick=""> and foo.onclick handlers and fire both?
>
> Mozilla, see the code earlier in the thread.

I tried the following test case in Mozilla Firefox 1.5.0.1 based on  
your example and only 3 is alerted:

<html>
<body>
<script>
document.body.onclick = function() { alert(2) }
document.body.setAttribute('onclick','alert(3)');
</script>
</body>
</html>

Regards,
Maciej

Received on Wednesday, 15 March 2006 21:56:35 UTC