> On Apr 25, 2015, at 9:28 AM, Anne van Kesteren <ann...@annevk.nl> 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 
> <https://gist.github.com/annevk/e9e61801fcfb251389ef>

var shadow = host.createShadowRoot({
  mode: "closed",
  distribute: (distributionList, insertionList) => {
    for(var i = 0; i < distributionList.length; i++) {
      for(var ii = 0; ii < insertionList.length; ii++) {
        var select = insertionList[ii].getAttribute("select")
        if(select != null && distributionList[i].matches(select)) {
        } else if(select != null) {

One major drawback of this API is computing insertionList is expensive because 
we'd have to either (where n is the number of nodes in the shadow DOM):
Maintain an ordered list of insertion points, which results in O(n) algorithm 
to run whenever a content element is inserted or removed.
Lazily compute the ordered list of insertion points when `distribute` callback 
is about to get called in O(n).

If we wanted to allow non-direct child descendent (e.g. grand child node) of 
the host to be distributed, then we'd also need O(m) algorithm where m is the 
number of under the host element.  It might be okay to carry on the current 
restraint that only direct child of shadow host can be distributed into 
insertion points but I can't think of a good reason as to why such a 
restriction is desirable.

- R. Niwa

Reply via email to