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

2015-05-03 Thread Wilson Page
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 dglaz...@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 ann...@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/





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

2015-05-01 Thread Dimitri Glazkov
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 ann...@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/