Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On Sat, 03 Jul 2010 00:09:53 +0200, Chris Wilson cwi...@microsoft.com wrote: Can you point me to where? Sorry, I thought you meant cancelable. The reason it does mention bubbling and cancelable explicitly but not capturing is because each event can always be captured, but not all of them bubble or can be canceled. It also matters for what Event.bubbles and Event.cancelable will return. -- Anne van Kesteren http://annevankesteren.nl/
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On Wed, 30 Jun 2010 22:39:48 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 6/29/10 2:36 PM, Chris Wilson wrote: See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. Note that the Firefox behavior I described is irrelevant to specification efforts, because it's not visible to web pages I think Anne answered the question, in any case: the XHR event target chain only contains the XHR object itself and nothing else. If the spec doesn't say that explicitly, it should. I do not think the XMLHttpRequest specification should state that to be honest. If that is at all unclear from the current specifications (and I am not particularly convinced) that should be clarified in DOM Events. There are plenty of objects around that implement EventTarget. Saying for every single one of them they are standalone is make work. -- Anne van Kesteren http://annevankesteren.nl/
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
* Jonas Sicking wrote: On Fri, Jul 2, 2010 at 1:29 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 30 Jun 2010 22:39:48 +0200, Boris Zbarsky bzbar...@mit.edu wrote: I think Anne answered the question, in any case: the XHR event target chain only contains the XHR object itself and nothing else. If the spec doesn't say that explicitly, it should. I do not think the XMLHttpRequest specification should state that to be honest. If that is at all unclear from the current specifications (and I am not particularly convinced) that should be clarified in DOM Events. There are plenty of objects around that implement EventTarget. Saying for every single one of them they are standalone is make work. Indeed. Seems like having the DOM Events spec say that EventTargets are standalone unless otherwise specified seems like a good idea. Well let's see: if you want to know what the XHR event flow is, then you have to read the XHR specification to see whether it specifies something different from the default regardless of whether it does or does not. If it does specify the event flow, then you are done. And if it does not you also have to read the DOM Events specification to learn the default. So, correct me if I am wrong, but having to read two specifications does not seem to be less work than having to read only one specification. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On Fri, 02 Jul 2010 12:57:08 +0200, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Anne van Kesteren wrote: You have to read DOM Events either way. Not to answer the particular question. Sure, you might have read the DOM Events specification, say, to figure out what Event.currentTarget is but what it means when a specification does not define the event flow you'd expect it to define is not something that will stick with most readers, they will have to consult the specification just to answer the question. You'd have to read it to figure out what the event flow is, for instance. (It's worse even, because some readers would not know where to check if the XHR specification does not define it, do they have to check the spe- cification for the `window` object aswell, or for the individual events, considering that the propagation paths sometimes depend on the type of event that is being dispatched, and others may jump to the conclusion it is left to the implementation or that it's the same as with whatever they are already familiar with, whatever that is.) The event flow with respect to some object should always be defined in the same place that defines that object to be an EventTarget, there is no point in optimizing the one sentence it takes to define it out using implicit indirection. I disagree. Only Node objects have event flow and the Window object interacts with those in a particular way. All other objects do not have an event flow at all. Optimizing for those other objects makes way more sense. -- Anne van Kesteren http://annevankesteren.nl/
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
* Anne van Kesteren wrote: You'd have to read it to figure out what the event flow is, for instance. Which is something that is much more likely to stick with you, yes. I disagree. Only Node objects have event flow and the Window object interacts with those in a particular way. All other objects do not have an event flow at all. Optimizing for those other objects makes way more sense. There is always an event flow even if the propagation path contains only a single EventTarget. Besides, there certainly are other hierachial ob- jects that are EventTargets but not Nodes, like SVGElementInstances or various objects in Adobe Flash et al., or entirely custom objects like you can make them with the implementation in Google's Closure Library. You'd have a point if nobody ever wondered how the XHR event flow works, but this isn't the first time questions about that have ended up here. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
RE: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
Jonas Sicking [mailto:jo...@sicking.cc] wrote: On Fri, Jul 2, 2010 at 1:29 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 30 Jun 2010 22:39:48 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 6/29/10 2:36 PM, Chris Wilson wrote: See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. I think Anne answered the question, in any case: the XHR event target chain only contains the XHR object itself and nothing else. If the spec doesn't say that explicitly, it should. I do not think the XMLHttpRequest specification should state that to be honest. If that is at all unclear from the current specifications (and I am not particularly convinced) that should be clarified in DOM Events. There are plenty of objects around that implement EventTarget. Saying for every single one of them they are standalone is make work. Indeed. Seems like having the DOM Events spec say that EventTargets are standalone unless otherwise specified seems like a good idea. ...and that's precisely what I was getting at, and why I asked what some appeared to take as an obvious question. It would be a good idea, imo, to establish the pattern: that events on non-DOM objects do not (unless they explicitly say so) get capturing/bubbling behavior. The place to do that would seem to be the DOM Events spec. BTW, the XHR spec does not say anything about capture, iirc, just bubbling - leaving it somewhat ambiguous. Thanks, -Chris
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On Fri, Jul 2, 2010 at 3:03 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Jonas Sicking wrote: On Fri, Jul 2, 2010 at 1:29 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 30 Jun 2010 22:39:48 +0200, Boris Zbarsky bzbar...@mit.edu wrote: I think Anne answered the question, in any case: the XHR event target chain only contains the XHR object itself and nothing else. If the spec doesn't say that explicitly, it should. I do not think the XMLHttpRequest specification should state that to be honest. If that is at all unclear from the current specifications (and I am not particularly convinced) that should be clarified in DOM Events. There are plenty of objects around that implement EventTarget. Saying for every single one of them they are standalone is make work. Indeed. Seems like having the DOM Events spec say that EventTargets are standalone unless otherwise specified seems like a good idea. Well let's see: if you want to know what the XHR event flow is, then you have to read the XHR specification to see whether it specifies something different from the default regardless of whether it does or does not. If it does specify the event flow, then you are done. And if it does not you also have to read the DOM Events specification to learn the default. So, correct me if I am wrong, but having to read two specifications does not seem to be less work than having to read only one specification. Like Anne points out, the XHR spec should really not specify the *event flow*. What it could specify is the propagation path, however I really don't think we want it to repeat what the DOM Events spec specifies as far as capturing/target/bubbling phases goes. That should IMO be defined by the DOM Events spec and the DOM Events spec only. Because of this, anyone that wants to know which event handlers are fired when will still have to read the DOM Events spec. Thus it doesn't seem like a loss of readability to have the DOM Events spec also define what the default propagation path is. / Jonas
RE: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
Can you point me to where? XHR L2 spec says To dispatch a readystatechange event means that an event with the name readystatechange, with no namespace, which does not bubble and is not cancelable, and which uses the Event interface, is to be dispatched at the XMLHttpRequest object. (end of section 2.2), but doesn't say anything about capturing - effectively raising the issue of event flow without directly mentioning it. DOM L3 Events spec says This document specifies an event flow for tree-based structures: DOM event flow... applications might reuse the interfaces defined in this document for non-tree-based structures. (Section 1.1.1) DOM L3 spec does describe the event flow as Each event has an event target, a targeted node in the case of the DOM Event flow, toward which the event is dispatched by the DOM Events implementation. (Section 1.2) I suppose one might consider that this means in the case of XHR, that since no non-tree based structure has been explicitly specified for XHR objects, that the dispatching is indeed directly on to the XHR object, but then it seems redundant and confusing to additionally state that the events do not bubble (but not refer to capturing), rather than simply saying explicitly There is no event flow outside of dispatching directly to the object. -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Friday, July 02, 2010 9:31 AM To: Jonas Sicking; Chris Wilson Cc: Boris Zbarsky; Brett Zamir; www-...@w3.org; public-webapps@w3.org; Travis Leithead; Adrian Bateman Subject: Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects On Fri, 02 Jul 2010 18:21:31 +0200, Chris Wilson cwi...@microsoft.com wrote: BTW, the XHR spec does not say anything about capture, iirc, just bubbling - leaving it somewhat ambiguous. It is actually quite explicit as far as I can tell. -- Anne van Kesteren http://annevankesteren.nl/
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On Tue, 29 Jun 2010 23:36:28 +0200, Chris Wilson cwi...@microsoft.com wrote: See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. The fact that the XHR spec says the events do not bubble (but says nothing about capture) is confusing. DOM L3 Events says here's what happens for DOM elements, but doesn't say explicitly if NOTHING should happen for non-DOM uses, or if something else should depending on context. If nothing is stated nothing needs to be done. That Firefox does something with an object outside the Window object as well is not relevant. DOM Events defines the event flow for document trees. HTML5 defines how events are dispatched to Window in the event they are dispatched to Document. Trying to infer anything else from any of this is a mistake. XMLHttpRequest is neither part of the document tree nor is it the Window object, so logically its events will not go anywhere. Specifications need to be read literally. We never say explicitly that NOTHING should happen. That is implied. Defining all the cases where NOTHING should happen is a race to the bottom. -- Anne van Kesteren http://annevankesteren.nl/
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On 6/29/10 2:36 PM, Chris Wilson wrote: See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. Note that the Firefox behavior I described is irrelevant to specification efforts, because it's not visible to web pages I think Anne answered the question, in any case: the XHR event target chain only contains the XHR object itself and nothing else. If the spec doesn't say that explicitly, it should. -Boris
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On 6/29/10 2:36 PM, Chris Wilson wrote: See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. Note that the Firefox behavior I described is irrelevant to specification efforts, because it's not visible to web pages I would really like to know (along the lines of the changed thread title) why other browsers are not, as it appears, interested in making this part of a specification effort. Although there might not yet be interest to make some official standard for browser add-ons at this point, I would think that in this one crucial area, browsers could consider allowing extension authors and web developers the ability to have a common means, regardless of browser, of communicating back-and-forth in the same protocol by using custom DOM events in this way as Firefox currently does. It is no small functionality to allow websites the abiility to communicate with add-ons and in an extensible manner. Despite being an advocate of open source and open formats myself, I strongly disagree with the sentiment I have heard some express, that the ability to make custom formats within X/HTML, whether through namespaced elements and attributes or processing instructions (both regrettably disallowed by HTML at present, in my view) or by custom DOM events, is only promoting proprietary formats. On the contrary, I feel that such ability to experiment allows new standards to emerge which meet needs that HTML is not presently willing to implement. Here are just a few use cases, though the list could really go on and on: 1) Allowing websites to interact with client-side chat clients for real-time collaboration by site visitors (as the Firefox extension SamePlace does) 2) Allowing websites to share and access each other's databases when permitted by the site (or even by the user alone) a) Adoption of more specific shared database formats in a specific genre like the ability to view, schedule, and edit meetings or events 3) Supporting the ability to query XML databases with powerful XQuery and update facilities through the browser. While it is great that the big browsers have settled on avoiding too extreme a competition with their own new markup, going through standards bodies at least in cases like video/ where there is no need for 1000 different ways to express the markup (even while the case could be made for allowing 1000 different namespaced attributes on the tag until standardization is complete), smaller sites or special interests if not bigger organizations as well, still need the ability to innovate. The web will clearly not settle for perpetually proprietary formats anyways, except in cases where the standards have not yet caught up. And proprietary here is a relative term since the underlying platform (DOM/XML) is still itself standardized. Better to give the means for innovation in the first place but in a way which can be made to work cross-browser, rather than shut the door and treat web innovators and users paternalistically if not outright domineering them by maintaining exclusive control in the name of their supposed interest. While it is great that web authors have not been precipitously forced to use XML, it is a pity, in my view, that the extensibility of XML has not been carried over and embraced, even if a co-editor of XML himself (reasonably) suggested avoiding creating new dialects where possible. Please give us at least one means of extending functionality beyond what you currently happen to support or want to support... Brett
RE: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. The fact that the XHR spec says the events do not bubble (but says nothing about capture) is confusing. DOM L3 Events says here's what happens for DOM elements, but doesn't say explicitly if NOTHING should happen for non-DOM uses, or if something else should depending on context. -Chris -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Friday, June 25, 2010 9:59 AM To: Brett Zamir Cc: Anne van Kesteren; www-...@w3.org; public-webapps@w3.org; Travis Leithead; Adrian Bateman; Chris Wilson Subject: Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects On 6/25/10 5:56 AM, Brett Zamir wrote: I guess in Firefox the document is all part of one big tree that includes the add-on markup, so propagation is indeed within the same DOM tree It's not, actually. In Firefox, an event will bubble from a Window to some object in the browser UI associated with that Window. This object is the same for a page and all its subframes. What this object is is effectively an implementation detail. Note that we plan to keep this behavior as we move to a multi-process architecture, at which point the event will effectively bubble across the process boundary. -Boris
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On 6/25/10 5:56 AM, Brett Zamir wrote: I guess in Firefox the document is all part of one big tree that includes the add-on markup, so propagation is indeed within the same DOM tree It's not, actually. In Firefox, an event will bubble from a Window to some object in the browser UI associated with that Window. This object is the same for a page and all its subframes. What this object is is effectively an implementation detail. Note that we plan to keep this behavior as we move to a multi-process architecture, at which point the event will effectively bubble across the process boundary. -Boris
