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

Here's one case of redistribution:
https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122

Any time you see <content> inside a custom element it's potentially
redistribution. Here there's on that is (line 122), and one that could be
(line 116), and one that definitely isn't (line 106).

I personally think that Hayato's analogy to function parameters is very
motivating. Arguing from use-cases at this point is going to miss many
things because so far we've focused on the most simple of components, are
having to rewrite them for Polymer 0.8, and haven't seen the variety and
complexity of cases that will evolve naturally from the community. General
expressiveness is extremely important when you don't have an option to work
around it - redistribution is one of these cases.

Cheers,
  Justin


On Wed, Apr 29, 2015 at 4:57 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> 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
>