Re: Shadow DOM Imperative API proposal #1 vs <content select/slot>

I was imagining the distribution chain would start at light-dom, recursing
deeper into the shadows. Meaning any <content> slot encountered would have
already been distributed to.

The `empty()` part feels messy to me. I preferred the way option 2 worked,
whereby distribution is 'invalidated' and reflowed (like layout). Wondering
what the use-case is for `slot.remove()` and retaining/mutating
distribution state. I guess it could potentially be more efficient to only
change the parts you need to? Still seems cumbersome to me.

*W I L S O N  P A G E*

Front-end Developer
Firefox OS (Gaia)
London Office

Twitter: @wilsonpage
IRC: wilsonpage

On Fri, May 1, 2015 at 6:32 PM, Dimitri Glazkov <dglazkov@google.com> wrote:

> Thanks Wilson and Anne!
>
> One interesting thing I noticed is that the algo relies on
> candidate.distributedNodes already being correctly populated by the nesting
> shadow tree. Does that mean that we'd need to ensure the correct order of
> invoking distribution among the nesting trees? Or maybe mutation observers
> already help you do that?
>
> :DG<
>
> On Fri, May 1, 2015 at 8:15 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
>> Wilson Page attempted to implement <content select> (with microtask
>> observers as a timing solution for the time being) to see whether that
>> proposal was workable:
>>
>>   https://gist.github.com/wilsonpage/d5520bd8d22327633e33
>>
>> Compared to how <content select> is implemented in #2 this looks
>> rather jarring and we're not even sure whether it's correct.
>>
>> If someone could confirm whether it's correct or provide a complete
>> solution I'd like to add it to the overall proposal page so that the
>> proposals can be more easily compared:
>>
>>
>> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md
>>
>> We should also provide a <content slot> implementation for the various
>> solutions to see whether they can meet that proposal. Though I think
>> as <content slot> was originally proposed the solution with #1 would
>> get equally complex due to having to do recursive unwrapping of
>> <content> elements in script. And the solution with #2 would be
>> equally simple.
>>
>> (I updated that page quite significantly by the way to clarify #1 a
>> bit, make #2 more readable, and also added some alternative solutions
>> to the timing problem.)
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>>
>