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

On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> 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.

I guess that is true if you know you're not going to modify your
insertion points or shadow tree. I would be happy to update the gist
to exclude this parameter and instead use something like

  shadow.querySelector("content")

somewhere. It doesn't seem important.


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

That seems doable.


>> So you mean that we'd turn distributionList into a subtree?
>
> 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>
> ```
>
> 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.

So if we did that, distributionList would become distributionRoot. And
whenever add() is invoked any node that is not a descendant of
distributionRoot or is a descendant of a node already add()'d would
throw? It seems that would get us a bit more complexity than the
current algorithm...


>> The other thing I would like to explore is what an API would look like
>> that does the subclassing as well.
>
> 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.

With the existence of closed shadow trees, it seems like you'd want to
allow for the superclass to not have to share its details with the
subclass.


-- 
https://annevankesteren.nl/

Received on Thursday, 30 April 2015 12:12:29 UTC