- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 30 Apr 2015 14:17:50 +0200
- To: Hayato Ito <hayato@chromium.org>
- Cc: Steve Orvell <sorvell@google.com>, Ryosuke Niwa <rniwa@apple.com>, Olli Pettay <olli@pettay.fi>, WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>
On Tue, Apr 28, 2015 at 12:31 AM, 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? The imperative API I proposed leaves the timing up to whenever distribute() is invoked by the developer. Currently at best that can be done from mutation observers. And I think that's fine for v1. element.offsetWidth et al are bad APIs that we should not accommodate for. The results they return will be deterministic, but they should not cause further side effects such as distribution and therefore the results might appear incorrect I suppose depending on what point of view you have. We discussed this point at the meeting. > 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. Only if you insist on coupling them are they similar. And only if you insist on semantics that are identical to <content select>. This is the very reason why <content select> is not acceptable as it would require solving that problem. Whereas an imperative API free of the warts of element.offsetWidth would not have to. -- https://annevankesteren.nl/
Received on Thursday, 30 April 2015 12:18:14 UTC