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

Reply via email to