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:41:29 +0200
Message-ID: <CADnb78j2gJ3-kv9tbd5DBWaGNa15b5iHLdnSJXeHXBOUP+XxOQ@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: Ryosuke Niwa <rniwa@apple.com>, Justin Fagnani <justinfagnani@google.com>, WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>, "Edward O'Connor" <eoconnor@apple.com>, Steve Orvell <sorvell@google.com>
On Thu, Apr 30, 2015 at 2:30 PM, Domenic Denicola <d@domenic.me> wrote:
> Can someone point me to the part of the spec that is problematic? That is,
> where is the line that says "UAs may run this algorithm at any time"? I am
> not sure what to Ctrl+F for.

At the end of section 3.4 it states "If any condition which affects
the distribution result changes, the distribution result must be
updated before any use of the distribution result." which basically
means you can't make use of a "dirty" tree.

> Secondly, could someone produce a code snippet that would cause such interop
> problems, given the current spec?

  var x = new Event(eventType)
  someNodeThatIsDistributed.addEventListener(eventType, e =>

> Finally, assuming we have such an example, would there be a way to tighten
> the spec language such that we don't need to specify e.g. when style
> recalculation happens, but instead specify constraints? Like "offsetTop must
> always reflect the redistributions" or something.

That is what the specification currently does and what prevents us
from defining an imperative API. For an imperative API it is
imperative (mahaha) that we get the timing with respect to tasks
right. (Or as per my proposal, leave timing up to developers.)

Received on Thursday, 30 April 2015 12:41:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:55 UTC