> On Apr 28, 2015, at 1:04 PM, Elliott Sprehn <espr...@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

Reply via email to