Shadow DOM: state of the distribution API

It seems we have three contenders for the distribution API.

1) Synchronous, no flattening of <content>. A host element's shadow
tree has a set of slots each exposed as a single <content> element to
the outside. Host elements nested inside that shadow tree can only
reuse slots from the outermost host element.

2) Synchronous, flattening of <content>. Any host element nested
inside a shadow tree can get anything that is being distributed.
(Distributed <content> elements are unwrapped and not distributed
as-is.)

3) Lazy. A distinct global (similar to the isolated Shadow DOM story)
is responsible for distribution so it cannot observe when distribution
actually happens.

The argument for 1 is that there are no (good?) use cases for 2 and
that descendants can be distributed, not just children. The argument
for 2 is that it can be used to implement <content select> and
<content slot> without much difficulty. The argument for 3 is that
distribution is a layout concept (despite also impacting non-UI events
and DOM APIs).

(1/2 also require something akin "nanotask" mutation observers.)

As I said elsewhere it's not clear to me we should couple DOM and
layout. The composed tree is distinct from the render tree. It's also
not clear to me what 3 would look like. No concrete proposal has been
made. What is clear to me given the experience with service workers is
that introducing a new global environment is not simple and would
likely set us back another couple of years.

That leaves 1/2 and although Ryosuke and Tab have taken sides, neither
has really backed up their story. I tried to explore 1 in
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0474.html
but that did not get much traction. So... trying again.


-- 
https://annevankesteren.nl/

Received on Wednesday, 6 May 2015 09:05:55 UTC