> 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
