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

Here's a minimal and hopefully simple proposal that we can flesh out if
this seems like an interesting api direction:

https://gist.github.com/sorvell/e201c25ec39480be66aa

We keep the currently spec'd distribution algorithm/timing but remove
`select` in favor of an explicit selection callback. The user simply
returns true if the node should be distributed to the given insertion point.

Advantages:
 * the callback can be synchronous-ish because it acts only on a specific
node when possible. Distribution then won't break existing expectations
since `offsetHeight` is always correct.
 * can implement either the currently spec'd `select` mechanism or the
proposed `slot` mechanism
 * can easily evolve to support distribution to isolated roots by using a
pure function that gets read only node 'proxies' as arguments.

Disadvantages:
 * cannot re-order the distribution
 * cannot distribute sub-elements

On Sat, Apr 25, 2015 at 1:58 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Apr 25, 2015, at 1:17 PM, Olli Pettay <olli@pettay.fi> wrote:
> >
> > On 04/25/2015 09:28 AM, Anne van Kesteren wrote:
> >> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >>> In today's F2F, I've got an action item to come up with a concrete
> workable
> >>> proposal for imperative API.  I had a great chat about this afterwards
> with
> >>> various people who attended F2F and here's a summary.  I'll continue
> to work
> >>> with Dimitri & Erik to work out details in the coming months (our
> deadline
> >>> is July 13th).
> >>>
> >>> https://gist.github.com/rniwa/2f14588926e1a11c65d3
> >>
> >> I thought we came up with something somewhat simpler that didn't
> >> require adding an event or adding remove() for that matter:
> >>
> >>   https://gist.github.com/annevk/e9e61801fcfb251389ef
> >
> >
> > That is pretty much exactly how I was thinking the imperative API to
> work.
> > (well, assuming errors in the example fixed)
> >
> > An example explaining how this all works in case of nested shadow trees
> would be good.
> > I assume the more nested shadow tree just may get some nodes, which were
> already distributed, in the distributionList.
>
> Right, that was the design we discussed.
>
> > How does the distribute() behave? Does it end up invoking distribution
> in all the nested shadow roots or only in the callee?
>
> Yes, that's the only reason we need distribute() in the first place.  If
> we didn't have to care about redistribution, simply exposing methods to
> insert/remove distributed nodes on content element is sufficient.
>
> > Should distribute callback be called automatically at the end of the
> microtask if there has been relevant[1] DOM mutations since the last
> > manual call to distribute()? That would make the API a bit simpler to
> use, if one wouldn't have to use MutationObservers.
>
> That's a possibility.  It could be an option to specify as well.  But
> there might be components that are not interested in updating distributed
> nodes for the sake of performance for example.  I'm not certain forcing
> everyone to always update distributed nodes is necessarily desirable given
> the lack of experience with an imperative API for distributing nodes.
>
> > [1] Assuming we want to distribute only direct children, then any child
> list change or any attribute change in the children
> > might cause distribution() automatically.
>
> I think that's a big if now that we've gotten rid of "select" attribute
> and multiple generations of shadow DOM.  As far as I could recall, one of
> the reasons we only supported distributing direct children was so that we
> could implement "select" attribute and multiple generations of shadow DOM.
>  If we wanted, we could always impose such a restriction in a declarative
> syntax and inheritance mechanism we add in v2 since those v2 APIs are
> supposed to build on top of this imperative API.
>
> Another big if is whether we even need to let each shadow DOM select nodes
> to redistribute.  If we don't need to support filtering distributed nodes
> in insertion points for re-distribution (i.e. we either distribute
> everything under a given content element or nothing), then we don't need
> all of this redistribution mechanism baked into the browser and the model
> where we just have insert/remove on content element will work.
>
> - R. Niwa
>
>
>