- From: <bugzilla@jessica.w3.org>
- Date: Fri, 21 Mar 2014 23:47:42 +0000
- To: public-webapps-bugzilla@w3.org
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