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

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


I want to be able to create an element <x-foo> that acts like other dom
elements. This element uses Shadow DOM and distribution to encapsulate its
details.

Let's imagine a 3rd party user named Bob that uses <div> and <x-foo>. Bob
knows he can call div.appendChild(element) and then immediately ask
div.offsetHeight and know that this height includes whatever the added
element should contribute to the div's height. Bob expects to be able to do
this with the <x-foo> element also since it is just another element from
his perspective.

How can I, the author of <x-foo>, craft my element such that I don't
violate Bob's expectations? Does your proposal support this?

On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

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