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:

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

Reply via email to