> On Apr 27, 2015, at 1:45 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>> On Apr 27, 2015, at 11:47 AM, Steve Orvell <sorv...@google.com 
>> <mailto: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)

I meant to say O(nk).  Sorry, I'm still waking up :(

> 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

Reply via email to