- From: Web APIs Issue Tracker <dean+cgi@w3.org>
- Date: Thu, 23 Mar 2006 01:19:13 +0000 (UTC)
- To: public-webapi@w3.org
ISSUE-50: Should capturing EventListeners registered on the target fire? http://www.w3.org/2005/06/tracker/webapi/issues/50 Raised by: Jonas Sicking On product: All Right now mozilla will fire capturing EventListeners registered on the target node of an element. So for something like myImg.addEventListener("click", gotClicked, true); if a click event is dispatched against myImg the gotClicked handler will be fired. It is not entierly clear in DOM Level 2 Events if this is how things should be. The relevant section [1] in the spec on one hand says: When the event reaches the target, any event listeners registered on the EventTarget are triggered. But then later in the section specifically on the capturing phase says: Event capture is the process by which an EventListener registered on an ancestor of the event's target can intercept events of a given type before they are received by the event's target. The section describing the "useCapture" argument to addEventListener says: Events which are bubbling upward through the tree will not trigger an EventListener designated to use capture. There is currently a bug [2] filed on mozilla where it is debated what the spec really calls for. (I don't see a reason why mozilla wouldn't change its behaviour if that is really what the spec says). One interpretation (A) is that capturing listeners will not fire during the bubbling phase, but that that phase is only the duration from after the event has fired against the target to after when it has fired against the document (or other toplevel node). Under this interpretation mozilla does the right thing. Another interpretation (B) is that capturing listeners are only fired during the capturing phase, which is the duration from before the event has fired on the document to after it has fired on the last ancestor (i.e. the parent) of the target. Under this interpretation mozilla should be changed. One advantage of interpretation A is that it lets you see non-bubbling events for an entire subtree by just registing one EventListener. For example if you are interested in if any node in a subtree is focused you just register a capturing listener on the root of that subtree. Under interpretation B you would not notice if the root got focused. Instead you would have to register both a capturing and a non-capturing EventListener. I can't offhand think of an advantage with B, but I don't think we want to break compatibility with DOM Level 2 Events if that is indeed what it says. In any event, this needs to be clarified in DOM Level 3 Events. / Jonas [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow [2] https://bugzilla.mozilla.org/show_bug.cgi?id=235441
Received on Thursday, 23 March 2006 01:23:17 UTC