Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
I just saw Dimitri's reference to my “Filling slots in shadow” blog posts from a while back, so I thought I’d follow up with the experiences I’ve had I wrote it. First, I remain convinced that it will be very helpful for Shadow DOM to provide a feature like this that allows for parent and child classes to cooperatively contribute elements to the same component. This is a key feature that enables well-factored user interface components. I started a company earlier this year that is building a site entirely on web components, and we’ve already hit the limitations of what’s possible without this feature. Second, my colleagues and I found the pre-existing proposal to let authors reproject content into to be an elegant solution to this problem. During the brief window when this feature was available in Chrome Canary, we quickly made use of it. It felt like a very natural extension of the Shadow DOM tree composition concepts we had already learned. That is, in our experience, the conceptual load introduced by this feature was low. To the extent the developer experience weighs in any decision here, we were completely fine with the approach of placing insertion points inside elements. Third, we feel a modest amount of impatience to see this feature implemented in Chrome again, and for other browsers to adopt this feature as it existed in Chrome. It was meeting our needs, and seeing it (even temporarily) removed felt like a step backwards. We’re concerned that lack of a solution here will discourage people from applying subclassing as a means to factor user interface behavior into parent/child component class relationships. Finally, even given all the above, we view it as more important that all the mainstream browsers implement the more fundamental aspects of Shadow DOM with all due speed. Our company and its customers are entirely dependent upon web components that use Shadow DOM, and while we can rely upon the Polymer library for cross-browser compatibility, there is a considerable different in performance between native and polyfilled Shadow DOM features. We test on a variety of browsers and devices, and while we can run on Mobile Safari or IE, performance on those platforms is barely acceptable. We would rather see the basics of Shadow DOM be native now, and live without defined semantics for parent/child contributions to shadow trees, than wait indefinitely for that feature before seeing native implementations of the basics. I feel like something of an industry outsider in discussions related to web standards, and appreciate the range of scenarios those working on standards must consider as they debate proposals for changes. I trust the smart folks at Apple, Google, and elsewhere to make the right decision here. All I can offer here is my company's own practical experience in this domain. For our part, we would be very happy to see a solution adopted in the standard that follows the general lines of allowing reprojection of content into elements, but in the meantime are primarily concerned with seeing native Shadow DOM implementations across all browsers. –Jan
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
Possibly relevant to the conversation: Jan Miksovsky (cc'd) had been thinking in this problem space for a while, and has a couple of great blog posts on the topic: http://blog.quickui.org/2013/11/08/filling-slots-in-shadow/ http://blog.quickui.org/2013/06/11/puzzle-define-html-custom-element-subclasses-that-can-fill-in-base-class-insertion-points/ :DG<
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Sun, Apr 27, 2014 at 2:36 PM, Ryosuke Niwa wrote: > On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov > wrote: > > BTW, here's a jsbin that implements yield/transclude using existing Shadow > DOM plumbing: > > http://jsbin.com/pacim/1/edit > > > Thanks for an example. That indeed polyfills the API we're proposing in > terms of the currently spec'ed API. > Great! > > One important aspect of our proposal is to avoid having to rely on > "shadowRoot" property on HTMLElement, which wouldn't exist in Type III > encapsulation. > Note, that the access to element's shadowRoot happens from the element's own implementation of a method. If I were a developer of a framework that implements the idea you suggested, I would do something like this: http://jsbin.com/pacim/4/edit > > On Apr 22, 2014, at 11:06 AM, Dimitri Glazkov > wrote: > > Here's a jsbin that uses the shadow-as-function syntax and does the same > thing: > > http://jsbin.com/peqoz/2/edit > > > This one doesn't quite work as intended in that the insertion points in > MyCardElement's shadow DOM could grab nodes from the light DOM. > Help me understand what you mean here. Which nodes will these insertion points grab? Would love an example. :DG<
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov wrote: > BTW, here's a jsbin that implements yield/transclude using existing Shadow > DOM plumbing: > > http://jsbin.com/pacim/1/edit Thanks for an example. That indeed polyfills the API we're proposing in terms of the currently spec'ed API. One important aspect of our proposal is to avoid having to rely on "shadowRoot" property on HTMLElement, which wouldn't exist in Type III encapsulation. On Apr 22, 2014, at 11:06 AM, Dimitri Glazkov wrote: > Here's a jsbin that uses the shadow-as-function syntax and does the same > thing: > > http://jsbin.com/peqoz/2/edit This one doesn't quite work as intended in that the insertion points in MyCardElement's shadow DOM could grab nodes from the light DOM. - R. Niwa
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Apr 22, 2014, at 10:13 AM, Dimitri Glazkov wrote:
> On Thu, Apr 17, 2014 at 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.
>
> Consider my-card element used as follows:
>
> Ryosuke Niwa
> rn...@apple.com
>
>
> Suppose this element's shadow DOM looks like this:
> Name:
> Email:
>
> Then in the composed tree, the first span is distributed into the first
> content element and the second span is distributed into the second content
> element as follows:
>
>
> Name:
>
> Ryosuke Niwa
>
>
> Email:
>
> rn...@apple.com
>
>
>
>
>
> If I had my-webkitten-card that always as "WebKitten" as a name that inherits
> from my-card, its shadow DOM may look like this:
>
> WebKitten
>
> kit...@webkit.org
>
>
> If I had an instance of my-webkitten-card as follows:
>
> Ryosuke Niwa
> rn...@webkit.org
>
>
> Then its composed tree will look like this:
>
>
>
>
> Name:
>
> WebKitten
> Ryosuke Niwa
>
>
> Email:
>
> rn...@webkit.org
> kit...@webkit.org
>
>
>
>
>
>
>
> Here, my-card's shadow DOM was inserted into where the shadow element existed
> in my-webkitten-card's shadow DOM, and the insertion points inside my-card's
> shadow DOM got nodes distributed from shadow element's children including
> nodes inside content element. If we didn't have the content element inside
> my-webkitten-card with "name" and "email" classes, then we would only see
> WebKitten and kit...@webkit.org distributed into my-card's insertion points
> as in:
>
>
>
>
>
> Name:
>
>
> WebKitten
>
>
> Email:
>
>
> kit...@webkit.org
>
>
>
>
>
>
>
> Can you help me understand the problems you illustrated with the examples
> better? What's the desired behavior? Where does the problem arise? This is
> both for my-webkitten-card and for random-element examples. I would love to
> have these to start chewing on them.
Sorry, maybe my description wasn't clear. This example doesn't demonstrate any
issues. I was simply describing what the current specification does.
- R. Niwa
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Apr 22, 2014, at 10:22 AM, Dimitri Glazkov wrote:
>
>
>
> On Thu, Apr 17, 2014 at 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.
>
> Consider my-card element used as follows:
>
> Ryosuke Niwa
> rn...@apple.com
>
>
> Suppose this element's shadow DOM looks like this:
> Name:
> Email:
>
> Then in the composed tree, the first span is distributed into the first
> content element and the second span is distributed into the second content
> element as follows:
>
>
> Name:
>
> Ryosuke Niwa
>
>
> Email:
>
> rn...@apple.com
>
>
>
>
>
> If I had my-webkitten-card that always as "WebKitten" as a name that inherits
> from my-card, its shadow DOM may look like this:
>
> WebKitten
>
> kit...@webkit.org
>
>
> If I had an instance of my-webkitten-card as follows:
>
> Ryosuke Niwa
> rn...@webkit.org
>
>
> Then its composed tree will look like this:
>
>
>
>
> Name:
>
> WebKitten
> Ryosuke Niwa
>
>
> Email:
>
> rn...@webkit.org
> kit...@webkit.org
>
>
>
>
>
>
>
> Here, my-card's shadow DOM was inserted into where the shadow element existed
> in my-webkitten-card's shadow DOM, and the insertion points inside my-card's
> shadow DOM got nodes distributed from shadow element's children including
> nodes inside content element. If we didn't have the content element inside
> my-webkitten-card with "name" and "email" classes, then we would only see
> WebKitten and kit...@webkit.org distributed into my-card's insertion points
> as in:
>
>
>
>
>
> Name:
>
>
> WebKitten
>
>
> Email:
>
>
> kit...@webkit.org
>
>
>
>
>
>
>
> Separating Transclusion Mechanisms for Inheritance and Data Binding
>
> The current model mixes data binding and inheritance if we consider
> distributing nodes from the "light DOM" as a form of data binding. Namely,
> distributing nodes from my-card's or my-webkitten-card's light DOM is data
> binding where the data model is DOM whereas distributing nodes from
> my-webkitten-card's shadow element into my-card's insertion points is an
> inheritance hook.
>
> Furthermore, the transclusion mechanism for inheritance happens backwards.
> Instead of a superclass defining a transclusion points for its subclasses to
> use, the subclasses are overriding the meaning of insertion points in the
> superclass by injecting nodes. This is how existing JS libraries and
> frameworks do template inheritance.
>
> For example, the following two JS template libraries that support inheritance
> both allow superclass template to define "named blocks" that could be
> overridden by subclass templates:
> http://paularmstrong.github.io/swig/docs/#inheritance
> http://jlongster.github.io/nunjucks/templating.html#template-inheritance
>
> An example from Nunjucks:
> If we have a template parent.html that looks like this:
>
> {% block header %}
> This is the default content
> {% endblock %}
>
>
> {% block left %}{% endblock %}
>
>
>
> {% block right %}
> This is more content
> {% endblock %}
>
> And we render this template:
>
> {% extends "parent.html" %}
>
> {% block left %}
> This is the left side!
> {% endblock %}
>
> {% block right %}
> This is the right side!
> {% endblock %}
> The output would be:
>
> This is the default content
>
>
> This is the left side!
>
>
>
> This is the right side!
>
>
> 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 distributi
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
*claps for sharing JSBin* Would love to see more of this on public-webapps when possible :) On Tue, Apr 22, 2014 at 10:46 AM, Dimitri Glazkov wrote: > BTW, here's a jsbin that implements yield/transclude using existing Shadow > DOM plumbing: > > http://jsbin.com/pacim/1/edit > > :DG< >
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
Here's a jsbin that uses the shadow-as-function syntax and does the same thing: http://jsbin.com/peqoz/2/edit :DG< On Tue, Apr 22, 2014 at 10:46 AM, Dimitri Glazkov wrote: > BTW, here's a jsbin that implements yield/transclude using existing Shadow > DOM plumbing: > > http://jsbin.com/pacim/1/edit > > :DG< >
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
BTW, here's a jsbin that implements yield/transclude using existing Shadow DOM plumbing: http://jsbin.com/pacim/1/edit :DG<
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Thu, Apr 17, 2014 at 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.
>
> Consider my-card element used as follows:
>
> Ryosuke Niwa
> rn...@apple.com
>
>
> Suppose this element's shadow DOM looks like this:
> Name:
> Email:
>
> Then in the composed tree, the first span is distributed into the first
> content element and the second span is distributed into the second content
> element as follows:
>
>
> Name:
>
> Ryosuke Niwa
>
>
> Email:
>
> rn...@apple.com
>
>
>
>
>
> If I had my-webkitten-card that always as "WebKitten" as a name that
> inherits from my-card, its shadow DOM may look like this:
>
> WebKitten
>
> kit...@webkit.org
>
>
> If I had an instance of my-webkitten-card as follows:
>
> Ryosuke Niwa
> rn...@webkit.org
>
>
> Then its composed tree will look like this:
>
>
>
>
> Name:
>
> WebKitten
> Ryosuke Niwa
>
>
> Email:
>
> rn...@webkit.org
> kit...@webkit.org
>
>
>
>
>
>
>
> Here, my-card's shadow DOM was inserted into where the shadow element
> existed in my-webkitten-card's shadow DOM, and the insertion points inside
> my-card's shadow DOM got nodes distributed from shadow element's children
> including nodes inside content element. If we didn't have the content
> element inside my-webkitten-card with "name" and "email" classes, then we
> would only see WebKitten and kit...@webkit.org distributed into my-card's
> insertion points as in:
>
>
>
>
>
> Name:
>
>
> WebKitten
>
>
> Email:
>
>
> kit...@webkit.org
>
>
>
>
>
>
>
> *Separating Transclusion Mechanisms for Inheritance and Data Binding*
>
> The current model mixes data binding and inheritance if we consider
> distributing nodes from the "light DOM" as a form of data binding. Namely,
> distributing nodes from my-card's or my-webkitten-card's light DOM is data
> binding where the data model is DOM whereas distributing nodes from
> my-webkitten-card's shadow element into my-card's insertion points is an
> inheritance hook.
>
> Furthermore, the transclusion mechanism for inheritance happens backwards.
> Instead of a superclass defining a transclusion points for its subclasses
> to use, the subclasses are overriding the meaning of insertion points in
> the superclass by injecting nodes. This is how existing JS libraries and
> frameworks do template inheritance.
>
> For example, the following two JS template libraries that support
> inheritance both allow superclass template to define "named blocks" that
> could be overridden by subclass templates:
> http://paularmstrong.github.io/swig/docs/#inheritance
> http://jlongster.github.io/nunjucks/templating.html#template-inheritance
>
> An example from Nunjucks:
>
> If we have a template parent.html that looks like this:
>
> {% block header %}This is the default content{% endblock %}
> {% block left %}{% endblock %}
> {% block right %} This is more content {% endblock
> %}
>
> And we render this template:
>
> {% extends "parent.html" %}
> {% block left %}This is the left side!{% endblock %}
> {% block right %}This is the right side!{% endblock %}
>
> The output would be:
>
> This is the default content
> This is the left side!
> This is the right side!
>
>
> *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 elem
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Thu, Apr 17, 2014 at 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.
>
> Consider my-card element used as follows:
>
> Ryosuke Niwa
> rn...@apple.com
>
>
> Suppose this element's shadow DOM looks like this:
> Name:
> Email:
>
> Then in the composed tree, the first span is distributed into the first
> content element and the second span is distributed into the second content
> element as follows:
>
>
> Name:
>
> Ryosuke Niwa
>
>
> Email:
>
> rn...@apple.com
>
>
>
>
>
> If I had my-webkitten-card that always as "WebKitten" as a name that
> inherits from my-card, its shadow DOM may look like this:
>
> WebKitten
>
> kit...@webkit.org
>
>
> If I had an instance of my-webkitten-card as follows:
>
> Ryosuke Niwa
> rn...@webkit.org
>
>
> Then its composed tree will look like this:
>
>
>
>
> Name:
>
> WebKitten
> Ryosuke Niwa
>
>
> Email:
>
> rn...@webkit.org
> kit...@webkit.org
>
>
>
>
>
>
>
> Here, my-card's shadow DOM was inserted into where the shadow element
> existed in my-webkitten-card's shadow DOM, and the insertion points inside
> my-card's shadow DOM got nodes distributed from shadow element's children
> including nodes inside content element. If we didn't have the content
> element inside my-webkitten-card with "name" and "email" classes, then we
> would only see WebKitten and kit...@webkit.org distributed into my-card's
> insertion points as in:
>
>
>
>
>
> Name:
>
>
> WebKitten
>
>
> Email:
>
>
> kit...@webkit.org
>
>
>
>
>
>
>
Can you help me understand the problems you illustrated with the examples
better? What's the desired behavior? Where does the problem arise? This is
both for my-webkitten-card and for random-element examples. I would love to
have these to start chewing on them.
:DG<
Re: [Shadow DOM] Separating Transclusion Mechanisms for Inheritance and Data Binding
On Apr 21, 2014, at 4:36 PM, William Chen wrote:
> 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 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.
Right.
> 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 element.
This is precisely what we don't like about the old specification that used the
shadow element as a function call semantics. It confuses data binding against
the "light" DOM and subclass inheritance hook. Furthermore, it ought be
superclass that opt-in to let subclass translate its content; not subclass that
transcludes arbitrary transclusion points its superclass defined for data
binding.
>> Alternative Approach to Inheritance
>>
>> 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):
>
>
>
> younger shadow root (subclass):
>
> Non-random Distribution
>
>
>
> light dom:
>
> This will not be distributed to the older
> shadow.
> This will be distributed to the older shadow.
>
>
> Again, this is only the case if the 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.
This wouldn't work if superclass weren't abstract. If an author instantiated
the superclass itself, there is nothing preventing the light DOM to have an
element that matches ".name". It's possible to work around this limitation by
treating the superclass as an abstract class and defining a subclass that works
around it but that strikes me as a terrible developer ergonomics story s
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 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 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):
younger shadow root (subclass):
Non-random Distribution
light dom:
This will not be distributed to the older
shadow.
This will be distributed to the older
shadow.
Again, this is only the case if the 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
Re: [Shadow DOM] Separating Transclusion Mechanisms for Inheritance and Data Binding
No, our proposal doesn't invoke multiple generations of shadow DOM. As such,
it works just fine without shadow element.
- R. Niwa
> On Apr 20, 2014, at 11:18 PM, Hayato Ito wrote:
>
> Thank you for the proposal.
>
> Sounds like the first part of the proposal is based on the feature which was
> reverted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24288.
> In the current spec, the child elements in are simply *ignored*.
> Therefore, I'm afraid that a shadow tree for my-webkitten-card:
>
>
> WebKitten
>
> kit...@webkit.org
>
>
> doesn't make sense here. That would be equivalent with a "".
>
> Does it have any affect for your proposal?
>
>
>
>> On Thu, Apr 17, 2014 at 6:43 PM, Ryosuke Niwa wrote:
>> Sorry, I forgot to add [Shadow DOM] in the title.
>>
>>> On Apr 17, 2014, at 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.
>>>
>>> Consider my-card element used as follows:
>>>
>>> Ryosuke Niwa
>>> rn...@apple.com
>>>
>>>
>>> Suppose this element's shadow DOM looks like this:
>>> Name:
>>> Email:
>>>
>>> Then in the composed tree, the first span is distributed into the first
>>> content element and the second span is distributed into the second content
>>> element as follows:
>>>
>>>
>>> Name:
>>>
>>> Ryosuke Niwa
>>>
>>>
>>> Email:
>>>
>>> rn...@apple.com
>>>
>>>
>>>
>>>
>>>
>>> If I had my-webkitten-card that always as "WebKitten" as a name that
>>> inherits from my-card, its shadow DOM may look like this:
>>>
>>> WebKitten
>>>
>>> kit...@webkit.org
>>>
>>>
>>> If I had an instance of my-webkitten-card as follows:
>>>
>>> Ryosuke Niwa
>>> rn...@webkit.org
>>>
>>>
>>> Then its composed tree will look like this:
>>>
>>>
>>>
>>>
>>> Name:
>>>
>>> WebKitten
>>> Ryosuke Niwa
>>>
>>>
>>> Email:
>>>
>>> rn...@webkit.org
>>> kit...@webkit.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Here, my-card's shadow DOM was inserted into where the shadow element
>>> existed in my-webkitten-card's shadow DOM, and the insertion points inside
>>> my-card's shadow DOM got nodes distributed from shadow element's children
>>> including nodes inside content element. If we didn't have the content
>>> element inside my-webkitten-card with "name" and "email" classes, then we
>>> would only see WebKitten and kit...@webkit.org distributed into my-card's
>>> insertion points as in:
>>>
>>>
>>>
>>>
>>>
>>> Name:
>>>
>>>
>>> WebKitten
>>>
>>>
>>> Email:
>>>
>>>
>>> kit...@webkit.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Separating Transclusion Mechanisms for Inheritance and Data Binding
>>>
>>> The current model mixes data binding and inheritance if we consider
>>> distributing nodes from the "light DOM" as a form of data binding. Namely,
>>> distributing nodes from my-card's or my-webkitten-card's light DOM is data
>>> binding where the data model is DOM whereas distributing nodes from
>>> my-webkitten-card's shadow element into my-card's insertion points is an
>>> inheritance hook.
>>>
>>> Furthermore,
Re: [Shadow DOM] Separating Transclusion Mechanisms for Inheritance and Data Binding
Thank you for the proposal.
Sounds like the first part of the proposal is based on the feature which
was reverted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24288.
In the current spec, the child elements in are simply *ignored*.
Therefore, I'm afraid that a shadow tree for my-webkitten-card:
WebKitten
kit...@webkit.org
doesn't make sense here. That would be equivalent with a
"".
Does it have any affect for your proposal?
On Thu, Apr 17, 2014 at 6:43 PM, Ryosuke Niwa wrote:
> Sorry, I forgot to add [Shadow DOM] in the title.
>
> On Apr 17, 2014, at 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.
>
> Consider my-card element used as follows:
>
> Ryosuke Niwa
> rn...@apple.com
>
>
> Suppose this element's shadow DOM looks like this:
> Name:
> Email:
>
> Then in the composed tree, the first span is distributed into the first
> content element and the second span is distributed into the second content
> element as follows:
>
>
> Name:
>
> Ryosuke Niwa
>
>
> Email:
>
> rn...@apple.com
>
>
>
>
>
> If I had my-webkitten-card that always as "WebKitten" as a name that
> inherits from my-card, its shadow DOM may look like this:
>
> WebKitten
>
> kit...@webkit.org
>
>
> If I had an instance of my-webkitten-card as follows:
>
> Ryosuke Niwa
> rn...@webkit.org
>
>
> Then its composed tree will look like this:
>
>
>
>
> Name:
>
> WebKitten
> Ryosuke Niwa
>
>
> Email:
>
> rn...@webkit.org
> kit...@webkit.org
>
>
>
>
>
>
>
> Here, my-card's shadow DOM was inserted into where the shadow element
> existed in my-webkitten-card's shadow DOM, and the insertion points inside
> my-card's shadow DOM got nodes distributed from shadow element's children
> including nodes inside content element. If we didn't have the content
> element inside my-webkitten-card with "name" and "email" classes, then we
> would only see WebKitten and kit...@webkit.org distributed into my-card's
> insertion points as in:
>
>
>
>
>
> Name:
>
>
> WebKitten
>
>
> Email:
>
>
> kit...@webkit.org
>
>
>
>
>
>
>
> *Separating Transclusion Mechanisms for Inheritance and Data Binding*
>
> The current model mixes data binding and inheritance if we consider
> distributing nodes from the "light DOM" as a form of data binding. Namely,
> distributing nodes from my-card's or my-webkitten-card's light DOM is data
> binding where the data model is DOM whereas distributing nodes from
> my-webkitten-card's shadow element into my-card's insertion points is an
> inheritance hook.
>
> Furthermore, the transclusion mechanism for inheritance happens backwards.
> Instead of a superclass defining a transclusion points for its subclasses
> to use, the subclasses are overriding the meaning of insertion points in
> the superclass by injecting nodes. This is how existing JS libraries and
> frameworks do template inheritance.
>
> For example, the following two JS template libraries that support
> inheritance both allow superclass template to define "named blocks" that
> could be overridden by subclass templates:
> http://paularmstrong.github.io/swig/docs/#inheritance
> http://jlongster.github.io/nunjucks/templating.html#template-inheritance
>
> An example from Nunjucks:
>
> If we have a template parent.html that looks like this:
>
> {% block header %}This is the default content{% endblock %}
> {% block left %}{% endblock %}
> {% block right %} This is more content {% endblock
> %}
>
> And we render this template:
>
> {% extends "parent.html" %}
> {% block left %}This is the left side!{% endblock %}
> {% block right %}This is the right side!{% endblock %}
>
> The output would be:
>
> This is the default content
> This
