W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

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

From: Ryosuke Niwa <rniwa@apple.com>
Date: Sat, 25 Apr 2015 13:49:52 -0700
Cc: WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>
Message-id: <DC7D99F0-7C00-4618-8677-088071E74066@apple.com>
To: Anne van Kesteren <annevk@annevk.nl>

> On Apr 25, 2015, at 9:28 AM, Anne van Kesteren <annevk@annevk.nl> 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 <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
Received on Saturday, 25 April 2015 20:50:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC