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

> On Apr 27, 2015, at 3:15 PM, Steve Orvell <sorvell@google.com> wrote:
> 
> 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.

I don't think we want to introduce O(nk) algorithm. Pretty much every browser optimization we implement these days are removing O(n^2) algorithms in the favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because we can't even theoretically optimize it away.

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

Indeed, running such an algorithm each time node is inserted or removed will be quite expensive.

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

I'm not necessarily saying that it's not good enough.  I'm just saying that it is possible to observe such a state even with this API.

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

You don't get that guarantee in the design we discussed on Friday [1] [2]. In fact, we basically deferred the timing issue to other APIs that observe DOM changes, namely mutation observers and custom elements lifecycle callbacks. Each component uses those APIs to call distribute().

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

Again, the timing was deferred in [1] and [2] so it really depends on when each component decides to distribute.

- R. Niwa

[1] https://gist.github.com/rniwa/2f14588926e1a11c65d3
[2] https://gist.github.com/annevk/e9e61801fcfb251389ef

Received on Monday, 27 April 2015 22:43:07 UTC