On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren <[email protected]> wrote: > On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov <[email protected]> > wrote: >> On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren <[email protected]> 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.
Yup. I don't understand whether you're just agreeing with me or disagreeing :) With shadow trees in place, we need to let them react to events happening in nodes, distributed to insertion points. > 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.) Can you elaborate on this a bit more. Note, you don't need to compute offsetX/Y until they are actually requested (which is what WebKit does anyway). > 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. I agree. That's not what I am proposing. >> 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.) Okay. :DG<
