W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2012

Re: [whatwg] seamless iframes and event propagation

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Thu, 6 Dec 2012 09:42:16 -0800
Message-ID: <CADh5Ky3-BjqwKxTudsWEadg776JC-0aZzEbCX1B-bW6dSaQ=ZA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
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 Wed, Dec 5, 2012 at 9:48 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
> > Yes, the intent is that in the the events from nodes, distributed to
> > insertion points should feel as if there wasn't any shadow tree around
> them.
>
> Right, but if <img> is inside the shadow tree (rather than distributed
> into it), you do not want its load/error events to leak? (Again, it
> would help if the principles behind those events were written down,
> e.g. soonish <img> will start dispatching progress events and who
> knows what it might dispatch in the future. That list does not address
> <video> either if the same would apply to that element.)
>

The basic idea here is that some events, when they are dispatched in a
shadow tree, are more likely implementation details that aren't useful
outside of this tree. For example, if an <img> with an image of a volume
control loads inside of a <video>, the author of <video> definitely doesn't
want the corresponding "load" event to leak out.

We could come up with some way to control this via a new API, but beware
the growl of complexity bear.


>
> So what I want is to tie this into the DOM's dispatch algorithm. The
> dispatch algorithm somehow needs to compute the ancestor chain and the
> current plan to do that is to follow an "event parent" chain (each
> EventTarget would have an "event parent" which is either null or some
> other object). However, it seems that is not quite enough for shadow
> DOM so instead we need to determine the "event parent" of an object
> algorithmically. I think we want "event parent for /event type/". So
> e.g. on ShadowRoot objects the "event parent for load" would be null,
> whereas for unicorn it would be its host element.
>
> Does that make sense?
>

This logic written down in great detail in Shadow DOM spec -- and tested in
an actual browser implementation. Would you consider transplanting it into
DOM dispatch?



>
> Ian, for HTML that would allow easily dealing with the load exception
> on Window too.
>
>
> --
> http://annevankesteren.nl/
>
Received on Thursday, 6 December 2012 17:42:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:50 UTC