> 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  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 . > 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  without running some script either synchronously or as a lifecycle callback in the world of an imperative API. - R. Niwa  https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0342.html  https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0344.html  https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0357.html