> 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
