On 04/27/2015 02:11 AM, Hayato Ito wrote:
I think Polymer folks will answer the use case of re-distribution.


I wasn't questioning the need for re-distribution. I was questioning the need 
to distribute grandchildren etc -
and even more, I was wondering what kind of algorithm would be sane in that 
case.

And passing random not-in-document, nor in-shadow-DOM elements to be 
distributed would be hard too.



So let me just show a good analogy so that every one can understand intuitively 
what re-distribution *means*.
Let me use a pseudo language and define XComponent's constructor as follows:

XComponents::XComponents(Title text, Icon icon) {
   this.text = text;
   this.button = new XButton(icon);
   ...
}

Here, |icon| is *re-distributed*.

In HTML world, this corresponds the followings:

The usage of <x-component> element:
   <x-components>
     <x-text>Hello World</x-text>
     <x-icon>My Icon</x-icon>
   </x-component>

XComponent's shadow tree is:

   <shadow-root>
     <h1><content select="x-text"></content></h1>
     <x-button><content select="x-icon"></content></x-button>
   </shadow-root>

Re-distribution enables the constructor of X-Component to pass the given 
parameter to other component's constructor, XButton's constructor.
If we don't have a re-distribution, XComponents can't create X-Button using the 
dynamic information.

XComponents::XCompoennts(Title text, Icon icon) {
   this.text = text;
   // this.button = new xbutton(icon);  // We can't!  We don't have 
redistribution!
   this.button = new xbutton("icon.png");  // XComponet have to do 
"hard-coding". Please allow me to pass |icon| to x-button!
   ...
}


On Sun, Apr 26, 2015 at 12:23 PM Olli Pettay <o...@pettay.fi 
<mailto:o...@pettay.fi>> wrote:

    On 04/25/2015 01:58 PM, Ryosuke Niwa wrote:
     >
     >> On Apr 25, 2015, at 1:17 PM, Olli Pettay <o...@pettay.fi 
<mailto: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 
<mailto: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.

    It is not clear to me at all how you would handle the case when a node has 
several ancestors with shadow trees, and each of those want to distribute
    the node to some insertion point.
    Also, what is the use case to distribute non-direct descendants?




     >  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
     >




Reply via email to