W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 27 Apr 2015 14:43:34 -0700
Cc: Olli Pettay <olli@pettay.fi>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>
Message-id: <B6FDD9C9-D7BC-4396-BA7D-9CEF9B3A004D@apple.com>
To: Steve Orvell <sorvell@google.com>

> On Apr 27, 2015, at 1:45 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> 
> 
>> On Apr 27, 2015, at 11:47 AM, Steve Orvell <sorvell@google.com <mailto:sorvell@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
> 
Received on Monday, 27 April 2015 21:44:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC