Re: [whatwg] ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
On Tue, 29 Jul 2008, Olli Pettay wrote: Chapter 5.4.4.3. Events and the Window object [1] says that event is also dispatched to window before (and after) dispatching to DOM nodes. I'd rather say window object is part of the event target chain (unfortunately load event is a special case), so events automatically propagate from document to window. No need to re-dispatch anything. (This is how gecko works ;) ) Or perhaps that is what the text is trying to say, but it should probably talk about event propagation, not about dispatching to window. I've tried to clarify this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
On Thu, 7 Aug 2008, Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. Is that any load event, or only specific load events? (i.e. is it a characteristic of the bubbling/capture process, or the events that are fired by certain circumstances like the end of parsing or an image being fetched from the network?) If the latter, it would be useful if the DOM3 Events spec could provde a hook for the HTML5 spec to annotate certain events as being affected by this exception. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
Ian Hickson wrote: On Thu, 7 Aug 2008, Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. Is that any load event, or only specific load events? (i.e. is it a characteristic of the bubbling/capture process, or the events that are fired by certain circumstances like the end of parsing or an image being fetched from the network?) If the latter, it would be useful if the DOM3 Events spec could provde a hook for the HTML5 spec to annotate certain events as being affected by this exception. I think it is all 'load' events except the one fired for the finished load of the actual page. I.e. loads for images, stylesheets, plugins, etc had to not reach the Window object. I'm uncertain if iframe loads reach the Window or not. / Jonas
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. / Jonas Sure, load events are special case, like mentioned in http://www.whatwg.org/specs/web-apps/current-work/#events0. Because of web compatibility the load event which is dispatched when a page is loaded has also other quirks, at least in gecko; it is dispatched to window, but its target is document. But in usual case events should propagate to .defaultView -Olli
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
On Fri, 8 Aug 2008, Jonas Sicking wrote: Is that any load event, or only specific load events? (i.e. is it a characteristic of the bubbling/capture process, or the events that are fired by certain circumstances like the end of parsing or an image being fetched from the network?) If the latter, it would be useful if the DOM3 Events spec could provde a hook for the HTML5 spec to annotate certain events as being affected by this exception. I think it is all 'load' events except the one fired for the finished load of the actual page. I.e. loads for images, stylesheets, plugins, etc had to not reach the Window object. I'm uncertain if iframe loads reach the Window or not. Would we want this to affect even author-dispatched synthetic load events? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
On Aug 7, 2008, at 11:27 PM, Jonas Sicking wrote: Ian Hickson wrote: On Thu, 7 Aug 2008, Olli Pettay wrote: Could we actually just say that if document implements DocumentView interface and .defaultView isn't null and implements EventTarget, the event propagates to .defaultView. So in that case defaultView becomes the root of the event target chain (if the target of the event is bound to document). No need to mention Window, since AbstractView is already defined in DOM2 Views[1]. HTML5 defines that AbstractView must also implement Window and EventTarget interfaces. [2] Fine by me, so long as the result is compatible with most UAs. One very unfortunate thing is that if i recall correctly the Window object never takes part in the EventTarget chain for the 'load' event. But does for all other events. This was because a lot of sites broke when we tried to bubble 'load' to the Window. I think it is best to special-case the 'load' event. We have this same quirk in WebKit. Regards, Maciej
Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
Chapter 5.4.4.3. Events and the Window object [1] says that event is also dispatched to window before (and after) dispatching to DOM nodes. I'd rather say window object is part of the event target chain (unfortunately load event is a special case), so events automatically propagate from document to window. No need to re-dispatch anything. (This is how gecko works ;) ) Or perhaps that is what the text is trying to say, but it should probably talk about event propagation, not about dispatching to window. -Olli [1] http://www.whatwg.org/specs/web-apps/current-work/#events0 Web Applications Working Group Issue Tracker wrote: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/44 Raised by: Ian Hickson On product: DOM3 Events We need to decide whether HTML5 or DOM3 Events (or another spec) defines how events interact with the Window object that browsers have. Right now HTML5 says this: http://www.whatwg.org/specs/web-apps/current-work/#events0 and DOM3 Events says this: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-flow
ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]
ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/44 Raised by: Ian Hickson On product: DOM3 Events We need to decide whether HTML5 or DOM3 Events (or another spec) defines how events interact with the Window object that browsers have. Right now HTML5 says this: http://www.whatwg.org/specs/web-apps/current-work/#events0 and DOM3 Events says this: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-flow
