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 11:32:08 -0800
Message-Id: <E1C9C5E4-F995-4186-90C8-4C127C57D872@apple.com>
Cc: "\"Web APIs WG (public)\"" <public-webapi@w3.org>
To: Jim Ley <jim@jibbering.com>


On Mar 14, 2006, at 3:01 AM, Jim Ley wrote:

>
> "Maciej Stachowiak" <mjs@apple.com>
>>> 1) Event listeners can not (and I also believe should not) be   
>>> capable of changing by modification of element attributes
>>
>> With the following test case, Safari, Firefox and Opera respect  
>> the  DOM change and reflect it with a changed event handler:
>
> I believe this is inconsistent behaviour, and should be changed:
>
> <script id=chicken>
> function chicken() { alert(1); }
> </script>
>
> and
>
> document.getElementById('chicken').firstChild.nodeValue="function  
> chicken() { alert(2); }"
>
> does not result in a change to the script, so it is unclear to me  
> why changing an attribute should be reflected in script.  Similarly  
> with XML event handlers and changing the content - currently they  
> do not get changed.
>
> Inconsistency is very annoying for the author.

1) Safari, Firefox, Opera and IE all have live event listener  
attributes. You are proposing that the spec should call for something  
incompatible with longstanding existing practice. You need to have a  
very strong argument if you want a change that contradicts all the  
major implementations and risks breaking existing content.

2) Consistency arguments could be made either way:

<img id="chicken" src="http://example.com/image1.gif">

document.getElementById('chicken').setAttribute("src", "http:// 
www.example.com/otherimage.jpg");

<textarea id="rooster" cols="60">
Sample text.
</textarea>

document.getElementById('rooster').setAttribute("cols", 80);

Or consider setting the href attribute of an <a> tag.

So for the vast majority of element attributes, changing the  
attribute value via the DOM changes the related appearance and  
behavior. It's not clear why you think it's more important for event  
listener attributes to be consistent with "other scripting stuff"  
than with other attributes.

3) It's safer to react to event listener attribute changes if user  
code thinks this will have no effect than to ignore them if the user  
code does think it will have this effect. Why? Well, you probably  
won't be changing the onclick attribute if you don't expect that to  
do anything.

4) <script> doesn't seem like a very relevant point of comparison.  
It's behavior is to execute a script once. It does not do something  
ongoing, and there is no way to un-execute a script. <script for> is  
a more relevant point of comparison, but it is a nonstandard IE  
extension and used more rarely than event listener attributes.  
Unclear why this should call for a change in event listener  
attributes instead of <script for>. XML events does not specify how  
or whether event listeners should respond to DOM changes to their  
contents or attributes, so if implementations do this it is more  
coincidence than design.

In summary, I do not think your scripting construct consistency  
argument does not outweigh the benefits of going with existing  
practice, and being consistent with other attributes.

Regards,
Maciej
Received on Tuesday, 14 March 2006 19:52:48 GMT

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