[whatwg] seamless iframes and event propagation
dglazkov at chromium.org
Fri Dec 7 09:38:18 PST 2012
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>
> > 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
> > want the corresponding "load" event to leak out.
> > We could come up with some way to control this via a new API, but beware
> > 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 (
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
> > This logic written down in great detail in Shadow DOM spec -- and tested
> > an actual browser implementation. Would you consider transplanting it
> > 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!
More information about the whatwg