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

--- Maciej Stachowiak <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)

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


> >  3) The current order of handlers execution is
> different in  
> > different browsers
> >    (take onload event that is first handled on
> window and then on  
> > body in IE, while fired first on body and then on
> window in Mozilla)
> 
> The load event does not fire on the body at all in
> Mozilla, as far as  
> I know. The following test case shows only "window".
> Same in the  
> latest builds of Safari. Opera fires body, then
> window, then  
> document, which seems weird. IE doesn't have
> addEventListener so this  
> test case won't work.
> 
> <html>
> <body>
> <script>
> window.addEventListener("load", function() {
> alert('window'); }, false);
> document.addEventListener("load", function() {
> alert('document'); },  
> false);
> document.documentElement.addEventListener("load",
> function() { alert 
> ('html element'); }, false);
> document.body.addEventListener("load", function() {
> alert('body  
> element'); }, false);
> </script>
> </body>
> </html>
> 
> 
> >  4) The scope of execution is currently very
> chaotic and very  
> > dependent on event types
> >    For example when handling onload/onunload event
> handlers, "this"  
> > object in IE points to window, while handlers for
> other event types
> >    properly get their scope of element objects.
> 
> I don't think it is chaotic in other browsers. But
> most browsers do  
> treat the onload property of <body> as creating a
> load event listener  
> on the window, not the body. So the "this" object
> binding isn't  
> arbitrary, it just reflects the true target of the
> event.
> 
> But I think specifying events on the window object
> is probably out of  
> scope for DOM Level 3 Events.
> 
> 
> >     I think the scope should never be dependent on
> the type of  
> > event and in any case get the scope of DOMElement
> Node to which the  
> > listener was added.
> 
> I'm assuming you mean this only for onfoo
> attribute-based event  
> listeners. This wouldn't be compatible with what
> browsers currently  
> do. But I think the html <body> and <html> elements
> might be the only  
> special cases. Perhaps also <frameset>.
> 
> Regards,
> Maciej
> 
> 
> 
> >
> >
> > Sergey Ilinsky,
> > Core Architect,
> > BackBase B.V.
> >
> > --- Jonas Sicking <jonas@sicking.cc> wrote:
> > >
> > > Maciej Stachowiak wrote:
> > > > Hi everyone,
> > > >
> > > > This action item was assigned to me while I
> wasn't
> > > present, so I'm not
> > > > sure what it means. I could imagine the
> following
> > > possible things
> > > > intended to be covered:
> > > >
> > > > 1) Define scope chain for event listeners
> attached
> > > via HTML event
> > > > attributes, e.g. <img
> > > onclick="handleClick(event)">.
> > > > 2) Define `this' binding behavior for #1.
> > > > 3) Define scope chain for events attached via
> HTML
> > > DOM properties, e.g.
> > > > myImage.onclick = handleClick
> > > > 4) Define `this' binding behavior for #3.
> > > > 5) Define scope chain for events attached via
> > > addEventListener().
> > > > 6) Define `this' binding for #5 (already
> done).
> > > > 7) Define scope chain for event listeners
> attached
> > > via SVG 1.1 event
> > > > attributes, e.g. <image
> > > onclick="handleClick(event)">.
> > > > 8) Define `this' binding behavior for #1.
> > > >
> > > > I do not feel like I have the relevant
> expertise
> > > to answer 7 and 8, but
> > > > I can try to do some research if it is
> desirable
> > > to define those.
> > >
> > > Ideally I would hope that we can define 7 and 8
> to
> > > be as similar to 1
> > > and 2 as possible, to reduce author confusion
> and
> > > make CDF more sane.
> > >
> > > > Here's brief outlines of the behavior I would
> > > propose. I have not tested
> > > > thoroughly or written any of this up in formal
> > > language, so please let
> > > > me know which ones need testing and formal
> > > language.
> > > >
> > > > 1) The attribute text is coverted to a
> function as
> > > if it were the result
> > > > of the following expression evaluated in
> global
> > > scope, where ELT is the
> > > > DOM object representing the element:
> > > >
> 
=== message truncated ===

Received on Tuesday, 14 March 2006 11:31:06 UTC