[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
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/



More information about the whatwg mailing list