Re: Shadow DOM: state of the distribution API

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? Synchronous
always has the downside that the developer has to deal with
reentrancy.

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.

/ Jonas

Received on Wednesday, 6 May 2015 17:58:36 UTC