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

On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> > One major drawback of this API is computing insertionList is expensive
> > because we'd have to either (where n is the number of nodes in the shadow
> > DOM):
> >
> > Maintain an ordered list of insertion points, which results in O(n)
> > algorithm to run whenever a content element is inserted or removed.
>

I don't expect shadow roots to be modified that much. We certainly don't
see it now, though the imperative API opens up some new possibilities like
calculating a grouping of child nodes and generating a <content> tag per
group, or even generating a <content> tag per child to perform decoration.
I still think those would be very rare cases.


> > Lazily compute the ordered list of insertion points when `distribute`
> > callback is about to get called in O(n).
>
> The alternative is not exposing it and letting developers get hold of
> the slots. The rationale for letting the browser do it is because you
> need the slots either way and the browser should be able to optimize
> better.
>
>
> > If we wanted to allow non-direct child descendent (e.g. grand child
> node) of
> > the host to be distributed, then we'd also need O(m) algorithm where m is
> > the number of under the host element.  It might be okay to carry on the
> > current restraint that only direct child of shadow host can be
> distributed
> > into insertion points but I can't think of a good reason as to why such a
> > restriction is desirable.
>

The main reason is that you know that only a direct parent of a node can
distribute it. Otherwise any ancestor could distribute a node, and in
addition to probably being confusing and fragile, you have to define who
wins when multiple ancestors try to.

There are cases where you really want to group element logically by one
tree structure and visually by another, like tabs. I think an alternative
approach to distributing arbitrary descendants would be to see if nodes can
cooperate on distribution so that a node could pass its direct children to
another node's insertion point. The direct child restriction would still be
there, so you always know who's responsible, but you can get the same
effect as distributing descendants for a cooperating sets of elements.


> So you mean that we'd turn distributionList into a subtree? I.e. you
> can pass all descendants of a host element to add()? I remember Yehuda
> making the point that this was desirable to him.
>
> The other thing I would like to explore is what an API would look like
> that does the subclassing as well. Even though we deferred that to v2
> I got the impression talking to some folks after the meeting that
> there might be more common ground than I thought.
>

I really don't think the platform needs to do anything to support
subclassing since it can be done so easily at the library level now that
multiple generations of shadow roots are gone. As long as a subclass and
base class can cooperate to produce a single shadow root with insertion
points, the platform doesn't need to know how they did it.

Cheers,
  Justin



> As for the points before about mutation observers. I kind of like just
> having distribute() for v1 since it allows maximum flexibility. I
> would be okay with having an option that is either optin or optout
> that does the observing automatically, though I guess if we move from
> children to descendants that gets more expensive.
>
>
> --
> https://annevankesteren.nl/
>
>