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: Mon, 27 Apr 2015 14:05:10 -0700
Cc: WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>
Message-id: <FC8660E3-1253-484D-9791-8B4216438D5A@apple.com>
To: Anne van Kesteren <annevk@annevk.nl>, Olli Pettay <olli@pettay.fi>

> On Apr 26, 2015, at 11:05 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
> On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 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).
> 
> The alternative is not exposing it and letting developers get hold of
> the slots. The rationale for letting the browser do it is because you
> need the slots either way and the browser should be able to optimize
> better.

I don’t think that’s true.  If you’re creating a custom element, you’re pretty much in the control of what goes into your shadow DOM.  I’m writing any kind of component that creates a shadow DOM, I’d just keep references to all my insertion points instead of querying them each time I need to distribute nodes.

Another important use case to consider is adding insertion points given the list of nodes to distribute.  For example, you may want to “wrap” each node you distribute by an element.  That requires the component author to know the number of nodes to distribute upfront and then dynamically create as many insertion points as needed.

>> 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.
> 
> So you mean that we'd turn distributionList into a subtree? I.e. you
> can pass all descendants of a host element to add()? I remember Yehuda
> making the point that this was desirable to him.

Consider table-chart component which coverts a table element into a chart with each column represented as a line graph in the chart. The user of this component will wrap a regular table element with table-chart element to construct a shadow DOM:

```html
<table-chart>
  <table>
    ...
      <td data-value=“253” data-delta=5>253 ± 5</td>
    ...
  </table>
</table-chart>
```

For people who like is attribute on custom elements, pretend it's
```html
  <table is=table-chart>
    ...
      <td data-value=“253” data-delta=5>253 ± 5</td>
    ...
  </table>
```

Now, suppose I wanted to show a tooltip with the value in the chart. One obvious way to accomplish this would be distributing the td corresponding to the currently selected point into the tooltip. But this requires us allowing non-direct child nodes to be distributed.


> The other thing I would like to explore is what an API would look like
> that does the subclassing as well. Even though we deferred that to v2
> I got the impression talking to some folks after the meeting that
> there might be more common ground than I thought.

For the slot approach, we can model the act of filling a slot as if attaching a shadow root to the slot and the slot content going into the shadow DOM for both content distribution and filling of slots by subclasses.

Now we can do this in either of the following two strategies:
1. Superclass wants to see a list of slot contents from subclasses.
2. Each subclass "overrides" previous distribution done by superclass by inspecting insertion points in the shadow DOM and modifying them as needed.

- R. Niwa
Received on Monday, 27 April 2015 21:05:39 UTC

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