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: Thu, 30 Apr 2015 22:11:36 -0700
Cc: Hayato Ito <hayato@chromium.org>, Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, 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>
Message-id: <2A303BB6-95CA-4996-B17D-95D65DD9D2FE@apple.com>
To: Elliott Sprehn <esprehn@chromium.org>

> On Apr 30, 2015, at 9:25 PM, Elliott Sprehn <esprehn@chromium.org> wrote:
> On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> ...
>> >
>> > The return value of (2) is the same in either case. There is no observable difference. No interop issue.
>> >
>> > Please file a bug for the spec with a concrete example if you can find a observable difference due to the lazy-evaluation of the distribution.
>> The problem isn't so much that the current shadow DOM specification has an interop issue because what we're talking here, as the thread title clearly communicates, is the imperative API for node distribution, which doesn't exist in the current specification.
>> In particular, invoking user code at the timing specified in section 3.4 which states "if any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result" introduces a new interoperability issue because "before any use of the distribution result" is implementation dependent.  e.g. element.offsetTop may or not may use the distribution result depending on UA.  Furthermore, it's undesirable to precisely spec this since doing so will impose a serious limitation on what UAs could optimize in the future.
> element.offsetTop must use the distribution result, there's no way to know what your style is without computing your distribution. This isn't any different than getComputedStyle(...).color needing to flush style, or getBoundingClientRect() needing to flush layout.

That is true only if the distribution of a given node can affect the style of element. There are cases in which UAs can deduce that such is not the case and optimize the style recalculation away. e.g. two elements belonging two different documents.

Another example will be element.isContentEditable. Under certain circumstances WebKit needs to resolve styles in order to determine the value of this function which, then, uses the distribution result.

> Distribution is about computing who your parent and siblings are in the box tree, and where your should inherit your style from. Doing it lazy is not going to be any worse in terms of interop than defining new properties that depend on style.

The problem is that different engines have different mechanism to deduce style dependencies between elements.

- R. Niwa
Received on Friday, 1 May 2015 05:12:06 UTC

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