For the record, I, as a spec editor, still think "Shadow Root hosts yet another Shadow Root" is the best idea among all ideas I've ever seen, with a "<shadow> as function", because it can explain everything in a unified way using a single tree of trees, without bringing yet another complexity such as multiple templates.
Please see https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22 On Tue, Apr 28, 2015 at 12:51 PM Ryosuke Niwa <rn...@apple.com> wrote: > > > On Apr 27, 2015, at 12:25 AM, Justin Fagnani <justinfagn...@google.com> > wrote: > > > > On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren <ann...@annevk.nl> > wrote: > >> On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa <rn...@apple.com> wrote: > >> > 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. > > That's an interesting approach. Ted and I discussed this design, and it > seems workable with Anne's `distribute` callback approach (= the second > approach in my proposal). > > Conceptually, we ask each child of a shadow host the list of distributable > node for under that child (including itself). For normal node without a > shadow root, it'll simply itself along with all the distribution candidates > returned by its children. For a node with a shadow root, we ask its > implementation. The recursive algorithm can be written as follows in pseudo > code: > > ``` > NodeList distributionList(Node n): > if n has shadowRoot: > return <ask n the list of distributable noes under n (1)> > else: > list = [n] > for each child in n: > list += distributionList(n) > return list > ``` > > Now, if we adopted `distribute` callback approach, one obvious mechanism > to do (1) is to call `distribute` on n and return whatever it didn't > distribute as a list. Another obvious approach is to simply return [n] to > avoid the mess of n later deciding to distribute a new node. > > >> 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. > > I think we should eventually add native declarative inheritance support > for all of this. > > One thing that worries me about the `distribute` callback approach (a.k.a. > Anne's approach) is that it bakes distribution algorithm into the platform > without us having thoroughly studied how subclassing will be done upfront. > > Mozilla tried to solve this problem with XBS, and they seem to think what > they have isn't really great. Google has spent multiple years working on > this problem but they come around to say their solution, multiple > generations of shadow DOM, may not be as great as they thought it would be. > Given that, I'm quite terrified of making the same mistake in spec'ing how > distribution works and later regretting it. > > In that regard, the first approach w/o distribution has an advantage of > letting Web developer experiment with the bare minimum and try out which > distribution algorithms and mechanisms work best. > > - R. Niwa > > >