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

On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
>>> On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>>> 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.
>>>
>>> At least the way I understand it, multiple shadow roots per element and
>>> distributions are largely orthogonal bits of machinery that solve largely
>>> orthogonal problems.
>>
>> Yes.  Distribution is mainly about making composition of components
>> work seamlessly, so you can easily pass elements from your light dom
>> into some components you're using inside your shadow dom.  Without
>> distribution, you're stuck with either:
>
> As I clarified my point in another email, neither I nor anyone else is questioning the value of the first-degree of node distribution from the "light" DOM into insertion points of a shadow DOM.  What I'm questioning is the value of the capability to selectively re-distribute those nodes in a tree with nested shadow DOMs.
>
>> * components have to be explicitly written with the expectation of
>> being composed into other components, writing their own <content
>> select> *to target the <content> elements of the outer shadow*, which
>> is also extremely terribad.
>
> Could you give me a concrete use case in which such inspection of content elements in the light DOM is required without multiple generations of shadow DOM?  In all the use cases I've studied without multiple generations of shadow DOM, none required the ability to filter nodes inside a content element.
>
>> Distribution makes composition *work*, in a fundamental way.  Without it, you simply don't have the ability to use components inside of components except in special cases.
>
> Could you give us a concrete example in which selective re-distribution of nodes are required? That'll settle this discussion/question altogether.

I'll let a Polymer person provide a concrete example, as they're the
ones that originally brought up redistribution and convinced us it was
needed, but imagine literally any component that uses more than one
<content> (so you can't get away with just distributing the <content>
element itself), being used inside of some other component that wants
to pass some of its light-dom children to the nested component.

Without redistribution, you can only nest components (using one
component inside the shadow dom of another) if you either provide
contents directly to the nested component (no <content>) or the nested
component only has a single distribution point in its own shadow.

~TJ

Received on Wednesday, 29 April 2015 23:58:22 UTC