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

>
> That might be an acceptable mode of operations. If you wanted to
> synchronously update your insertion points, rely on custom element's
> lifecycle callbacks and you can only support direct children for
> distribution.


That's interesting, thanks for working through it. Given a
`childrenChanged` callback, I think your first proposal
`<content>.insertAt` and `<content>.remove` best supports a synchronous
mental model. As you note, re-distribution is then the element author's
responsibility. This would be done by listening to the synchronous
`distributionChanged` event. That seems straightforward.

Mutations that are not captured in childrenChanged that can affect
distribution would still be a problem, however. Given:

    <div id="host">
      <div id="child"></div>
    </div>

    child.setAttribute('slot', 'a');
    host.offsetHeight;

Again, we are guaranteed that parent's offsetHeight includes any
contribution that adding the slot attribute caused (e.g. via a
#child[slot=a] rule)

If the `host` is a custom element that uses distribution, would it be
possible to have this same guarantee?

    <x-foo id="host">
      <div id="child"></div>
    </x-foo>

    child.setAttribute('slot', 'a');
    host.offsetHeight;








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

>
> > On Apr 27, 2015, at 4:41 PM, Steve Orvell <sorvell@google.com> wrote:
> >
> >> 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?
>
> In order to support this use case, the author of x-foo must use some
> mechanism to observe changes to x-foo's child nodes and involve
> `distribute` synchronously.  This will become possible, for example, if we
> added childrenChanged lifecycle callback to custom elements.
>
> That might be an acceptable mode of operations. If you wanted to
> synchronously update your insertion points, rely on custom element's
> lifecycle callbacks and you can only support direct children for
> distribution. Alternatively, if you wanted to support to distribute a
> non-direct-child descendent, just use mutation observers to do it at the
> end of a micro task.
>
> - R. Niwa
>
>