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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 30 Apr 2015 14:17:50 +0200
Message-ID: <CADnb78gEEcavumO6tkVufGotwa9HvHVhpTZk7iWv=-7DPcz4Tg@mail.gmail.com>
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.

Received on Thursday, 30 April 2015 12:18:14 UTC

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