[whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov <dglazkov at chromium.org>
> wrote:
> > 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.
>
> It sounds though like you'd want a different approach to this. What if
> I have a <video> as my implementation detail?
>

Then you probably don't want the "load" events of <video> escaping out of
the shadow tree, just as the spec provides.

It's an interesting question, though. Along with "load", such
implementation detail may dispatch a whole bunch of other events (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents
).

Most of these events--at least, following my reasoning--seem like they
should just be kept in the shadow tree.

I wonder if we would be better off reversing the condition and stopping ALL
events, except a set of events whose meaning stays clear after retargeting
(like "click").


> > 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?
>
> Well, eventually we might want to merge the whole DOM part of Shadow
> DOM and DOM I think, but for now my proposition was that dispatch
> calculates its tree in terms of asking for the event parent of a
> certain even type from an object. Shadow DOM could use that concept to
> define what the parent is. E.g. for a shadow root it would be the
> associated element, or not if the event type is something you do not
> want to leak, etc.
>

I think that's cool. cc' me on bug/patch, I want to review it.


>
> That way when specifications use the dispatch algorithm it
> automatically makes sense in the Shadow DOM rather than that you have
> to monkey-patch whatever Shadow DOM says on top of DOM, which is
> rather bad way of writing specifications.
>

Yay! Moar hooks!

:DG<