On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa <rn...@apple.com> wrote:
> > > On May 5, 2015, at 11:55 AM, Tab Atkins Jr. <jackalm...@gmail.com> > wrote: > > > > On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa <rn...@apple.com> wrote: > >>> On May 4, 2015, at 10:20 PM, Anne van Kesteren <ann...@annevk.nl> > wrote: > >>> > >>>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn <espr...@chromium.org> > wrote: > >>>> We can solve this > >>>> problem by running the distribution code in a separate scripting > context > >>>> with a restricted (distribution specific) API as is being discussed > for > >>>> other extension points in the platform. > >>> > >>> That seems like a lot of added complexity, but yeah, that would be an > >>> option I suppose. Dimitri added something like this to the imperative > >>> API proposal page a couple of days ago. > >>> > >>> > >>>> One thing to consider here is that we very much consider distribution > a > >>>> style concept. It's about computing who you inherit style from and > where you > >>>> should be in the box tree. It just so happens it's also leveraged in > event > >>>> dispatch too (like pointer-events). It happens asynchronously from DOM > >>>> mutation as needed just like style and reflow though. > >>> > >>> I don't really see it that way. The render tree is still computed from > >>> the composed tree. The composed tree is still a DOM tree, just > >>> composed from various other trees. In the "open" case you can access > >>> it synchronously through various APIs (e.g. >>> if we keep that for > >>> querySelector() selectors and also deepPath). > >> > >> I agree. I don't see any reason node distribution should be considered > as a style concept. It's a DOM concept. There is no CSS involved here. > > > > Yes there is. As Elliot stated in the elided parts of his quoted > > response above, most of the places where we update distribution are > > for CSS or related concerns: > > > > # 3 event related > > # 3 shadow dom JS api > > These two are nothing to do with styles or CSS. > > I'd like to inform all guys in this thread that Composed Tree is for resolving CSS inheritance by the definition. See the "Section 2.4 Composed Trees" in the spec: http://w3c.github.io/webcomponents/spec/shadow/#composed-trees Let me quote: > If an element doesn't participate in a composed tree whose root node is a document, the element must not appear in the formating structure [CSS21] nor create any CSS box. This behavior must not be overridden by setting the 'display' property. > In resolving CSS inheritance, an element must inherit from the parent node in the composed tree, if applicable. The motivation of a composed tree is to determine the parent node in resolving CSS inheritance. There is no other significant usages, except for event path. > >> I have issues with the argument that we should do it lazily. On one > hand, if node distribution is so expensive that we need to do it lazily, > then it's unacceptable to make event dispatching so much slower. On the > other hand, if node distribution is fast, as it should be, then there is no > reason we need to do it lazily. > >> > >> The problem is really the redistributions. If we instead had explicit > insertion points under each shadow host, then we wouldn't really need > redistributions at all, and node distribution can happen in O(1) per child > change. > > > > As repeatedly stated, redistribution appears to be a necessity for > > composition to work in all but the most trivial cases. > > Where? I have not yet to see a use case for which selective > redistribution of nodes (i.e. redistributing only a non-empty strict subset > of nodes from an insertion point) are required. > > - R. Niwa > >