Re: Shadow DOM: state of the distribution API

> On May 6, 2015, at 10:57 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 
> On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> 
>> 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.
> 
> Has at-end-of-microtask been debated rather than 1/2?

Yes. 1 and 2 don't really specify when as Anne pointed out. Timing is discussed separately at [1].

> Synchronous always has the downside that the developer has to deal with reentrancy.

I think we can make the same argument we made for custom elements. Since the distribution is done by each shadow DOM's implementation, there is a clear ownership. We also can't think of a use case in which `distribute` must be called recursively so we might want to ban it altogether (and throw) if that were the concern.

> End-of-microtask does have the downside that API calls which
> synchronously return layout information get the "wrong" values. Or
> rather, values that might change at end of microtask.
> 
> But calling sync layout APIs is generally a bad idea for perf anyway.
> If we introduced async versions of getComputedStyle,
> getBoundingClientRect etc, then we could make those wait to return a
> value until all content had been distributed into insertion points.
> 
> Of course, adding async layout accessors is a non-trivial project, but
> it's long over due.

I think the biggest concern with this approach is that it essentially forces the existing web pages to be rewritten in order to adopt shadow DOM. I'm not certain if it's the end of the world but it will surely raise the barrier of using shadow DOM.

[1] https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md#api-for-triggering-distribution

Received on Wednesday, 6 May 2015 22:43:10 UTC