[Bug 23887] [Shadow] Put only the final destination insertion point to the event path

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887

--- Comment #54 from Dimitri Glazkov <dglazkov@chromium.org> ---
(In reply to Olli Pettay from comment #47)
> (In reply to Steve Orvell from comment #43)
> > Let's go back to this case in
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c39 and review the
> > counter-argument.
> > 
> >     <content select=".header"></content>
> >     <content select=".content"></content>
> > 
> > 
> > > Why? Add a listener to the shadow host? You can easily filter out events in the 
> > > listener, for example by using the content.getDistributedNodes().
> > > Or you can add listeners to the distributed nodes themselves.
> > 
> > Neither option is acceptable.
> > 
> > If a listener is added to the shadowRoot, then each handler must start at
> > event.target and walk up the tree checking if the element is in the specific
> > content's list of distributed nodes. This has a non-trivial cost in code and
> > performance.
> Making propagation path more complicated has also performance cost, and
> makes event propagation inconsistent.

I agree on this point. The key here is deciding whether we should carry this
burden as a platform or pass it on to developers.

> Also, it is rather trivial cost in code, and makes code less unexpected,
> since
> propagation path doesn't have inconsistencies.

A good general exercise here is to assume that each shadow root chunk is
written by different people at different times. As a rule, these developers
should not need to have any insight into how these chunks are composed. In
other words, if I as a developer have to defensively anticipate what will
happen outside of my shadow tree, we failed the main objective of this whole
shadow DOM exercise -- composition.

Having all insertion points included in the event path satisfies this
constraint very well. As a developer, I have a consistent, simple way to find
out what events are being dispatched in the parts of the outer tree that are
distributed to my insertion points.

Having no insertion points included in the event path also satisfies this
constraint, and it's pretty clear that our guinea pig developer (Steve) already
worked around this problem by simply putting a div around the insertion point.

Having only final insertion point included in event path is craziness, because
now I, as a developer of my component may or may not receive an event depending
on how some other dude/dudette composed it in their app. That's composition
fail.

So, to keep on moving, we should just zap the insertion points altogether from
the event path.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 21 March 2014 23:47:44 UTC