On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov <dglaz...@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/
