- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 11 Jan 2013 19:10: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 Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote: > On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren <annevk@annevk.nl> wrote: >> 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.) > > Okay, so event path would be (in tree order): > > <a> -- [shadow root] -> .. -> <insertion point> -- <b> -- [shadow > root] -> .. -> <c> > > In this case, the adjustment happens twice, at <b> and <a>. Normally with <b> being a child of <a> there would not be any adjustment. If as you say offsetX/offsetY would be computed at invoke listener time, you just created an observable effect of implementing something in terms of shadow trees. (Which might not even be web-compatible.) I'm not sure that's desirable or even possible. Also, computing anything but target/relatedTarget at a point target might not even be in the DOM anymore seems very weird and counter to how the event model has worked thus far. > As I mentioned before, it's not solely based on WebKit implementation > experience. Microsoft had a very similar list for viewlink and they > wanted me to look at it when I was working on this part of the spec: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804 Note that IE did not have a capture phase back then. So just saying "stopping" makes some amount of sense. With a capture phase you need to do something else. (I filed a bug on this the other day.) -- http://annevankesteren.nl/
Received on Friday, 11 January 2013 18:10:50 UTC