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 <rn...@apple.com> wrote: > > > On Apr 25, 2015, at 1:17 PM, Olli Pettay <o...@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 <rn...@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 > > >
