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

I think there are a lot of user operations where distribution must be
updated before returning the meaningful result synchronously.
Unless distribution result is correctly updated, users would take the dirty
result.

For example:
- element.offsetWidth:  Style resolution requires distribution. We must
update distribution, if it's dirty, before calculation offsetWidth
synchronously.
- event dispatching: event path requires distribution because it needs a
composed tree.

Can the current HTML/DOM specs are rich enough to explain the timing when
the imperative APIs should be run in these cases?

For me, the imperative APIs for distribution sounds very similar to the
imperative APIs for style resolution. The difficulties of both problems
might be similar.





On Tue, Apr 28, 2015 at 7:18 AM 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.
>
> 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
>>
>>
>