[whatwg] seamless iframes and event propagation
dglazkov at chromium.org
Thu Dec 6 09:42:16 PST 2012
On Wed, Dec 5, 2012 at 9:48 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov <dglazkov at chromium.org>
> > 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
> 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
> Ian, for HTML that would allow easily dealing with the load exception
> on Window too.
More information about the whatwg