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

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 27 Apr 2015 15:54:03 -0700
Cc: Steve Orvell <sorvell@google.com>, Olli Pettay <olli@pettay.fi>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>
Message-id: <7984F1EF-682E-486F-872A-DEA553E15F85@apple.com>
To: Hayato Ito <hayato@chromium.org>

> On Apr 27, 2015, at 3:31 PM, Hayato Ito <hayato@chromium.org> wrote:
> I think there are a lot of user operations where distribution must be updated before returning the meaningful result synchronously.
> Unless distribution result is correctly updated, users would take the dirty result.


> For example:
> - element.offsetWidth:  Style resolution requires distribution. We must update distribution, if it's dirty, before calculation offsetWidth synchronously.
> - event dispatching: event path requires distribution because it needs a composed tree.
> Can the current HTML/DOM specs are rich enough to explain the timing when the imperative APIs should be run in these cases?

It certainly doesn't tell us when style resolution happens. In the case of event dispatching, it's impossible even in theory unless we somehow disallow event dispatching within our `distribute` callbacks since we can dispatch new events within the callbacks to decide to where a given node gets distributed. Given that, I don't think we should even try to make such a guarantee.

We could, however, make a slightly weaker guarantee that some level of conditions for the user code outside of `distribute` callbacks. For example, I can think of three levels (weakest to strongest) of self-consistent invariants:
1. every node is distributed to at most one insertion point.
2. all first-order distributions is up-to-date (redistribution may happen later).
3. all distributions is up-to-date.

> For me, the imperative APIs for distribution sounds very similar to the imperative APIs for style resolution. The difficulties of both problems might be similar.

We certainly don't want to (in fact, we'll object to) spec the timing for style resolution or what even style resolution means.

- R. Niwa
Received on Monday, 27 April 2015 22:54:32 UTC

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