Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On May 5, 2015, at 11:55 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> >
> > On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >>> On May 4, 2015, at 10:20 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >>>
> >>>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn <esprehn@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
>
>