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

Sergey Ilinsky wrote:
> --- Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>> wrote:
>  
>  >
>  >
>  > On Mar 14, 2006, at 1:01 AM, Sergey Ilinsky wrote:
>  >
>  > > Hello everyone,
>  > >
>  > > To the discussion kept here I'd like to add
>  > several important 
>  > > issues that have not been yet taken into
>  > consideration.
>  > >
>  > > 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:
>  >
>  >
>  > <div id="a" onclick="alert('original')"
>  > style="width: 200; height: 
>  > 200; background-color: red;"></div>
>  > <br>
>  > <br>
>  > <div id="b"
>  > onclick="document.getElementById('a').setAttribute
>  > ('onclick', 'alert(\'new\')');">
>  >    click here to change above listener
>  > </div>
>  >
> got it. but i would not think of this behaviour as of correct one since 
> script (elements/properties etc.) 
> has not that much to do with markup (tags/atributes)

I'm not sure I agree with you here. In mozilla we always strive towards 
that a DOM produced through DOM modifications should always behave as if 
you had had markup that produced that same DOM. I.e. the current DOM is 
what matters, not how you arrived to it.

The only exception to that I can think of is modifying <script> 
elements. This is because we can't undo the effect the of the script 
element.

>  > >  2) Since element can have any amount of listeners
>  > of the same 
>  > > event type attached, the construction
>  > >    element.on<handler> = fHandler;
>  > >    becomes ambigous (what is being reassigned by
>  > this call - a 
>  > > collection or the last one listener added or
>  > something else?).
>  > >    This is to be defined.
>  >
>  > <element onsomeevent=""> and element.onsomeevent =
>  > fHandler refer to 
>  > a single, unique listner per element. There is
>  > exactly one such "html 
>  > event listener" per event per element, but there can
>  > be any number of 
>  > addEventListener-added listeners at the same time.
>  >
> Well, still there is problem of event handlers processing order:
>  
> Suppose you added several listeners to an element by calling 
> addEventListener (for FF) or attachEvent (for IE).
> element.addEventListener("click", function(event){alert(1)}, false);
> element.addEventListener("click", function(event){alert(2)}, false);
> element.addEventListener("click", function(event){alert(3)}, false);
> or
> element.attachEvent("onclick", function(event){alert(1)});
> element.attachEvent("onclick", function(event){alert(2)});
> element.attachEvent("onclick", function(event){alert(3)});
>  
> And now you are trying to modificate the property of the element 
> corresponding to "html handler"
> element.onclick = function(event){alert(4)};
>  
> in FF you will get 1234 after clicking on element
> and in IE yo will get 4123.
>  
> What is the proper way (i guess FF)? Should it be defined?

Yes! It should definitely be defined. This "wasn't a problem" in DOM 
Level 2 Events since firing order was undefined.

However since Level 3 now defines the order to be the order in which the 
elements were registered we should decide if modifications to on* 
attribute and properties counts as unregistering the old handler and 
registering a new one, or modifying the existing one.

I think it should count as the former, so doing either
element.setAttribute('onclick', 'alert(4)')
or
element.onclick = function() { alert(4) }

should fire that handler after any previously registered handlers.

/ Jonas

Received on Wednesday, 15 March 2006 00:49:00 UTC