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

>
> Perhaps we need to make childrenChanged optionally get called when
> attributes of child nodes are changed just like the way you can configure
> mutation observers to optionally monitor attribute changes.


Wow, let me summarize if I can. Let's say we have (a) a custom elements
synchronous callback `childrenChanged` that can see child adds/removes and
child attribute mutations, (b) the first option in the proposed api here
https://gist.github.com/rniwa/2f14588926e1a11c65d3, (c) user element code
that wires everything together correctly. Then, unless I am mistaken, we
have enough power to implement something like the currently spec'd
declarative `select` mechanism or the proposed `slot` mechanism without any
change to user's expectations about when information in the dom can be
queried.

Do the implementors think all of that is feasible?

Possible corner case: If a <content> is added to a shadowRoot, this should
probably invalidate the distribution and redo everything. To maintain a
synchronous mental model, the <content> mutation in the shadowRoot subtree
needs to be seen synchronously. This is not possible with the tools
mentioned above, but it seems like a reasonable requirement that the
shadowRoot author can be aware of this change since the author is causing
it to happen.


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

>
> > On Apr 27, 2015, at 5:43 PM, Steve Orvell <sorvell@google.com> wrote:
> >>
> >> 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;
>
> That's a good point. Perhaps we need to make childrenChanged optionally
> get called when attributes of child nodes are changed just like the way you
> can configure mutation observers to optionally monitor attribute changes.
>
> - R. Niwa
>
>