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

> On Apr 28, 2015, at 1:04 PM, Elliott Sprehn <esprehn@chromium.org> wrote:
> 
> A distribute callback means running script any time we update distribution, which is inside the style update phase (or event path computation phase, ...) which is not a location we can run script.

That's not what Anne and the rest of us are proposing. That idea only came up in Steve's proposal [1] that kept the current timing of distribution.

> I also don't believe we should support distributing any arbitrary descendant, that has a large complexity cost and doesn't feel like simplification. It makes computing style and generating boxes much more complicated.

That certainly is a trade off. See a use case I outlined in [2].

> A synchronous childrenChanged callback has similar issues with when it's safe to run script, we'd have to defer it's execution in a number of situations, and it feels like a duplication of MutationObservers which specifically were designed to operate in batch for better performance and fewer footguns (ex. a naive childrenChanged based distributor will be n^2).

Since the current proposal is to add it as a custom element's lifecycle callback (i.e. we invoke it when we cross UA code / user code boundary), this shouldn't be an issue. If it is indeed an issue, then we have a problem with a lifecycle callback that gets triggered when an attribute value is modified.

In general, I don't think we can address Steve's need to make the consistency guarantee [3] without running some script either synchronously or as a lifecycle callback in the world of an imperative API.

- R. Niwa

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0342.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0344.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0357.html

Received on Tuesday, 28 April 2015 20:21:20 UTC