> On Apr 27, 2015, at 11:47 AM, Steve Orvell <sorv...@google.com> wrote: > > Here's a minimal and hopefully simple proposal that we can flesh out if this > seems like an interesting api direction: > > https://gist.github.com/sorvell/e201c25ec39480be66aa > <https://gist.github.com/sorvell/e201c25ec39480be66aa>
It seems like with this API, we’d have to make O(n^k) calls where n is the number of distribution candidates and k is the number of insertion points, and that’s bad. Or am I misunderstanding your design? > > We keep the currently spec'd distribution algorithm/timing but remove > `select` in favor of an explicit selection callback. What do you mean by keeping the currently spec’ed timing? We certainly can’t do it at “style resolution time” because style resolution is an implementation detail that we shouldn’t expose to the Web just like GC and its timing is an implementation detail in JS. Besides that, avoiding style resolution is a very important optimizations and spec’ing when it happens will prevent us from optimizing it away in the future/ Do you mean instead that we synchronously invoke this algorithm when a child node is inserted or removed from the host? If so, that’ll impose unacceptable runtime cost for DOM mutations. I think the only timing UA can support by default will be at the end of micro task or at UA-code / user-code boundary as done for custom element lifestyle callbacks at the moment. > The user simply returns true if the node should be distributed to the given > insertion point. > > Advantages: > * the callback can be synchronous-ish because it acts only on a specific > node when possible. Distribution then won't break existing expectations since > `offsetHeight` is always correct. “always correct” is somewhat stronger statement than I would state here since during UA calls these shouldDistributeToInsertionPoint callbacks, we'll certainly see transient offsetHeight values. - R. Niwa
