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

IMO, the appeal of this proposal is that it's a small change to the current
spec and avoids changing user expectations about the state of the dom and
can explain the two declarative proposals for distribution.


> 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?


I think you've understood the proposed design. As you noted, the cost is
actually O(n*k). In our use cases, k is generally very small.

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.


Running this callback at the UA-code/user-code boundary seems like it would
be fine. Running the more complicated "distribute all the nodes" proposals
at this time would obviously not be feasible. The notion here is that since
we're processing only a single node at a time, this can be done after an
atomic dom action.

“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.


Yes, you're right about that. Specifically it would be bad to try to read
`offsetHeight` in this callback and this would be an anti-pattern. If
that's not good enough, perhaps we can explore actually not working
directly with the node but instead the subset of information necessary to
be able to decide on distribution.

Can you explain, under the initial proposal, how a user can ask an
element's dimensions and get the post-distribution answer? With current dom
api's I can be sure that if I do parent.appendChild(child) and then
parent.offsetWidth, the answer takes child into account. I'm looking to
understand how we don't violate this expectation when parent distributes.
Or if we violate this expectation, what is the proposed right way to ask
this question?

In addition to rendering information about a node, distribution also
effects the flow of events. So a similar question: when is it safe to call
child.dispatchEvent such that if parent distributes elements to its
shadowRoot, elements in the shadowRoot will see the event?

On Mon, 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> 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
>
>
> 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
>
>