Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-07-03 Thread Anne van Kesteren
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

2010-07-02 Thread Anne van Kesteren

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

2010-07-02 Thread Bjoern Hoehrmann
* 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

2010-07-02 Thread Anne van Kesteren
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

2010-07-02 Thread Bjoern Hoehrmann
* 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

2010-07-02 Thread Chris Wilson
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

2010-07-02 Thread Jonas Sicking
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

2010-07-02 Thread Chris Wilson
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

2010-06-30 Thread Anne van Kesteren
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

2010-06-30 Thread Boris Zbarsky

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

2010-06-30 Thread Brett Zamir

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

2010-06-29 Thread Chris Wilson
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



Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-25 Thread Brett Zamir

On 6/25/2010 5:09 PM, Anne van Kesteren wrote:
On Wed, 23 Jun 2010 01:53:51 +0200, Travis Leithead 
tra...@microsoft.com wrote:
This topic came up internally on the IE team, and we thought it would 
be noteworthy to put this question before the working groups in hopes 
of getting a spec clarification made.


The question is: for XHR and other non-DOM related objects that 
support the EventTarget interface, meaning objects that will be 
surfaced off of window but aren't really a part of the markup tree, 
how should event propagation be handled?


Events only propagate within a DOM tree. In addition there are some 
special cases for the global object noted in the HTML5 specification. 
Other than that there is no propagation.


This is I guess a bit unrelated, but I was wondering whether thought 
been given to allowing custom events to allow formal propagation beyond 
the document (as described in 
https://developer.mozilla.org/en/Code_snippets/Interaction_between_privileged_and_non-privileged_pages#Sending_data_from_chrome_to_unprivileged_document 
) in a way that works cross-browser?


Although this is more suitable for small-scale experimentation rather 
than formal APIs (especially with events not allowing formal 
namespaces), it would be nice to have a method for allowing 
web-extension communication that could potentially be expanded to work 
in more than one browser, especially as other browsers enhance their 
add-on infrastructure.  (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, but not sure whether other browsers treat 
add-ons as fully separate, or if there is at least interest to make them 
work the same way.)


Brett




Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-25 Thread Boris Zbarsky

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