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

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.

How does the distribute() behave? Does it end up invoking distribution in all the nested shadow roots or only in the callee?

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.
(even then one could skip distribution say for example during page load time and do a page level "distribute all the stuff" once all the data is ready 
etc, if wanted.).




-Olli

[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 added an example there that shows how you could implement <content
> select>, it's rather trivial with the matches() API. I think you can
> derive any other use case easily from that example, though I'm willing
> to help guide people through others if it is unclear. I guess we might
> still want positional insertion as a convenience though the above
> seems to be all you need primitive-wise.
>
>

Received on Saturday, 25 April 2015 20:18:12 UTC