[whatwg] seamless iframes and event propagation

[Anne van Kesteren]

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?


>> 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?

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.

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.


-- 
http://annevankesteren.nl/