[whatwg] seamless iframes and event propagation

Anne van Kesteren annevk at annevk.nl
Fri Jan 11 10:10:23 PST 2013

On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov <dglazkov at chromium.org> wrote:
> On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren <annevk at 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

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.)


More information about the whatwg mailing list