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

Shadow DOM: state of the distribution API

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 6 May 2015 11:05:33 +0200
Message-ID: <CADnb78gM3oPVB-Ne+9+g2N1CuacPctgc9Q-ZpEpjbYA7qBOVBQ@mail.gmail.com>
To: WebApps WG <public-webapps@w3.org>
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

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
but that did not get much traction. So... trying again.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:56 UTC