- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 9 Jan 2013 22:42:23 +0100
- To: Dimitri Glazkov <dglazkov@chromium.org>
- Cc: Hayato Ito <hayato@chromium.org>, whatwg <whatwg@lists.whatwg.org>, Eric Seidel <eric@webkit.org>, Ian Hickson <ian@hixie.ch>, Adam Barth <w3c@adambarth.com>, Ojan Vafai <ojan@chromium.org>
On Tue, Jan 8, 2013 at 6:32 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote: > 1) For a tree <a> -- [shadow root] -> <b> -- [shadow root] -> <c> > (where "->" denotes child-parent relationship and "--" denotes > host-root relationship) > 2) if an event is dispatched on <c> > 3) where is the event target's adjusted? > > If that's the question, then it needs to be adjusted twice: at <b> > (the adjusted target becomes <b>) and at <a> (the adjusted target > becomes <a>). My bad, I actually meant if <a>'s associated shadow tree had an insertion point through which <a>'s child, which is <b>, would go and then the event would be dispatched in <b>'s associated shadow tree. (I phrased that beyond poorly however and only tried to make up for it on IRC.) >>> 3) Also when invoking event listeners >>> (http://dom.spec.whatwg.org/#concept-event-listener-invoke), between steps 3 >>> and 4, we have to: >>> >>> a) if the type of event is MouseEvent, adjust offsetX and offsetY relative >>> to relative target. >>> >>> b) If the type of event has a relatedTarget attribute (MouseEvent, >>> FocusEvent), adjust it using >>> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-related-target-algorithm. >> >> Are you sure this happens at that point? Because at that point the DOM >> could have completely changed due to event callbacks. > > That's a good point. In WebKit implementation, the tuple mentioned in > #1 also contains relatedTarget, but I neglected to mention this in the > spec. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20604. So why are offsetX and offsetY not calculated in advance? Those would be affected by DOM manipulation in event listeners too. (If you have all those attributes being different, would it not be easier to use a different event object?) Incidentally, was there any progress made on the magic list of events that should not leak out of the upper boundary? If that list is based on implementation experience of certain widgets in WebKit, maybe it would be better if those widgets instead themselves took care of those events not leaking through by having the appropriate event listeners? Hmm, I guess that might not work for capturing... :/ -- http://annevankesteren.nl/
Received on Wednesday, 9 January 2013 21:42:48 UTC