[whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> 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.

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<