- From: David Flanagan <dflanagan@mozilla.com>
- Date: Mon, 04 Jul 2011 14:49:23 -0700
- To: www-dom@w3.org
I'm having trouble reading and writing email today :-) I mistakenly replied to Olli off-list, but as everyone can see, he replied to my original message on-list. So just disregard it all. Sorry! On 7/4/11 2:38 PM, David Flanagan wrote: > Please disregard this message. I just received an off-list reply > pointing out that IndexedDB propagates events on a non-DOM tree, and > that capturing events can fire during the AT_TARGET phase. My > questions are answered and the spec is correct as it stands > > David > > On 7/4/11 2:14 PM, David Flanagan wrote: >> The "dispatch an event" algorithm branches depending on whether the >> event target is "participating in a tree". At first, I was thinking >> about nodes only and assumed this test was checking whether >> parentNode was null or not, since capturing and bubbling don't make >> sense for nodes that have no parent. But the definition of >> "participating in a tree" just says that the object has a parent >> (even if it is null) and children.... >> >> Does the language really need to be this general? Are events ever >> dispatched on trees that are not document trees? I don't think that >> events ever bubble up a tree of frames, do they? >> >> So couldn't the algorithm branch based on whether target is a Node >> and parentNode is non-null instead of the vaguer and more confusing >> "participating in a tree" test? >> >> And here's a related question... I've never tried registering a >> capturing event handler on a non-Node event target like an XHR. Such >> an event handler could never be invoked, though. So should the >> addEventListener() method include the "participates in a tree" test >> and throw an exception if the 3rd argument is true? >> >> David > >
Received on Monday, 4 July 2011 21:49:52 UTC