- From: Randy Drielinger <Randy@ProWebDesign.nl>
- Date: Wed, 19 May 2010 11:58:36 +0200
> Of course, in a theoretical future where we'd add an object "above" > the Window object, these events would bubble to that object. But > that's not the case today as no such object exists. This is actually already used nowadays. Whenever you implement a browser object in another application (like the IE object in Visual Studio), you can capture these bubbled events in your application. Good thing that it actually stayed in the specs :) We use that in our call scripter tool for contact center agents. Regards ----- Original Message ----- From: "Jonas Sicking" <jonas@sicking.cc> To: "David Flanagan" <david at davidflanagan.com> Cc: <whatwg at lists.whatwg.org> Sent: Tuesday, May 18, 2010 12:12 AM Subject: Re: [whatwg] Window events that bubble? On Mon, May 17, 2010 at 3:07 PM, David Flanagan <david at davidflanagan.com> wrote: > Section 6.5.9 "History Traversal" defines popstate and hashchange events > that are fired on the Window object. It specifies that these events *must* > bubble. Where should they bubble to? What does it mean to bubble up from a > Window? These events aren't going across frames, are they? > > Is the specification that they must bubble a formality because existing > implementations set the bubbles property of the Event object to true? Or > does it actually have some impact on event propagation? My understanding is that the only noticable effect of defining that these effects bubble is that their bubbles property is set to true. Same thing happens to bubbling events fired at an XMLHttpRequest object. Of course, in a theoretical future where we'd add an object "above" the Window object, these events would bubble to that object. But that's not the case today as no such object exists. / Jonas
Received on Wednesday, 19 May 2010 02:58:36 UTC