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

Re: Shadow DOM: state of the distribution API

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 6 May 2015 10:57:38 -0700
Message-ID: <CA+c2ei-einAdz1jEeXyV1Qt-m4akZAQ+KzgNTkdwpLw76psb4w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebApps WG <public-webapps@w3.org>
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

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC