- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Fri, 7 Dec 2012 09:38:18 -0800
- 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 Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov <dglazkov@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<
Received on Friday, 7 December 2012 17:38:49 UTC