Re: [Shadow DOM] Separating Transclusion Mechanisms for Inheritance and Data Binding

On 4/17/14, 2:42 AM, Ryosuke Niwa wrote:
> *Review: Template Inheritance in the Current Specification*
>
> In the current specification, a super class doesn't define any hooks
> for subclasses.  Instead, it defines insertion points into which nodes
> from the original DOM ("light DOM") is inserted, and then subclasses
> use shadow element to replace elements that get distributed into
> superclass's insertion points.
I'm going to assume that you were writing this email against the version
of the spec that had <shadow> as a function call semantics since that's
what it looks like from your examples, so I will respond as if that
feature is still there to address some of your points. It also looks
like the behavior might come back because the bug removing it says: "
revert it to the old behavior until we find a reasonable idea of the
implementation".

Content insertion points in the super class select nodes from the
subclasses shadow element, except when there is no subclass, in which
case it selects from the light DOM. Thus you can use insertion points to
act like an inheritance hook for subclasses. It is up to the subclass to
decide if it wants to propagate any nodes from the light DOM into the
super class using its own insertion points within the <shadow> element.
> *Alternative Approach to Inhertiance*
>
> Consider random-element which picks a random child node to show
> whenever a user clicks on the element.  This element may show the name
> of probability distribution it uses to pick a child in its shadow DOM.
>  The name of the probability distribution is in the definitions of
> subclasses of random-element, and not in the light DOM of this custom
> element.  If we wanted to use the current inheritance model (multiple
> generations of shadow DOM & shadow element), we have to either replace
> the entire shadow DOM in the subclass to show the name of the
> probability distribution that subclasses use or add an attribute, etc…
> to identify the element that contains the name of probability
> distribution inside subclasses' shadow element. The latter would be
> weird because there is nothing preventing from the user of
> random-element to put an element that matches the same selector as a
> child of random-element in the "light DOM".
The super class could have an insertion point for the distribution name
selecting on a class, etc. The way distribution worked was that the
older shadow root would only distribute child nodes from the younger
shadow root's shadow element, so the subclass has a great degree of
control over distributed nodes. The only way to leak the user's nodes
from the "light DOM" would be if the subclass pulled nodes from the
user's "light DOM" with content insertion points in the shadow element.
Simplified example:

older shadow root (superclass):
<content select=".name"></content>
<content select=".pickme"></content>

younger shadow root (subclass):
<shadow>
    <span class="name">Non-random Distribution</span>
    <content select=".pickme"></content>
</shadow>

light dom:
<random-element>
    <span class="name">This will not be distributed to the older
shadow.</span>
    <span class="pickme">This will be distributed to the older
shadow.</span>
</random-element>

Again, this is only the case if the <shadow> as function call gets added
back to the spec.
> For implementors, this new model doesn't require multiple generations
> of shadow DOM for a single host.  Each element can have at most one
> shadow root, and its shadow DOM simply contain yield element that
> defines transclusion point.  Furthermore, transclusion is simply done
> as attaching a new shadow DOM to yield element.  If we wanted the same
> expressive power as the current inheritance model in grabbing light
> DOM's nodes, we can make insertion points pull nodes out of the parent
> shadow DOM's light DOM instead.
>
> For authors, the new model separates the concerns of binding DOM data
> model to shadow DOM from defining inheritance hooks.  It addresses use
> cases where inheritance hooks for subclasses are separate from data
> source used by custom elements such as random-element showing the name
> of distribution, which is overridden by its subclasses.
It seems like we can use insertion points as both inheritance hooks and
data binding right now to solve the same use cases as yield. I'm not too
sure I understand what we gain from yield that we can't do otherwise. I
do like the idea about separating data binding and inheritance hooks,
but I'm not sure yield is the way to do it. We sometimes treat DOM nodes
as data, and other times we don't, in the end we just transclude them in
a very similar way so any distinction between the two would be mostly
syntactic. There would be little in the way of people abusing data
bindings as insertion hooks or insertion hooks as data bindings. I think
if we wanted to make the distinction, we would need a data insertion
point that transcludes something that looks more like data than an
arbitrary DOM node.

- William