Re: Separating Transclusion Mechanisms for Inheritance and Data Binding

2014-04-30 Thread Jan Miksovsky
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 shadow 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 content insertion points inside shadow 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 shadow 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

2014-04-28 Thread Dimitri Glazkov
On Sun, Apr 27, 2014 at 2:36 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov dglaz...@chromium.org
 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 dglaz...@chromium.org
 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

2014-04-28 Thread Dimitri Glazkov
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

2014-04-27 Thread Ryosuke Niwa

On Apr 22, 2014, at 10:22 AM, Dimitri Glazkov dglaz...@chromium.org wrote:

 
 
 
 On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com 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:
   my-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@apple.com/span
   /my-card
 
 Suppose this element's shadow DOM looks like this:
 Name: content select=.name/content
 Email: content select=.email/content
 
 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:
   my-card
 !-- shadow root begin --
 Name: content select=.name
   !-- distribution begin --
   span class=nameRyosuke Niwa/span
   !-- distribution end --
 /content
 Email: content select=.email
   !-- distribution begin --
   span class=emailrn...@apple.com/span
   !-- distribution end --
   /content
 !-- shadow root end --
   /my-card
 
 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:
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow
 
 If I had an instance of my-webkitten-card as follows:
   my-webkitten-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@webkit.org/span
   /my-webkitten-card
 
 Then its composed tree will look like this:
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
   shadow
   !-- my-card's shadow root begin --
   Name: content select=.name
 !-- distribution begin --
 span class=nameWebKitten/span
 span class=nameRyosuke Niwa/span
 !-- distribution end --
   /content
   Email: content select=.email
 !-- distribution begin --
 span class=emailrn...@webkit.org/span
 span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card
 
 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:
 
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
 shadow
   !-- my-card's shadow root begin --
   Name:
   content select=.name
 !-- distribution begin --
   span class=nameWebKitten/span
 !-- distribution end --
   /content
   Email:
   content select=.email
 !-- distribution begin --
   span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card
 
 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 %}
 
 section class=left
   {% block left %}{% endblock %}
 /section
 
 section class=right
   {% block right %}
   This is more content
   {% endblock

Re: Separating Transclusion Mechanisms for Inheritance and Data Binding

2014-04-27 Thread Ryosuke Niwa
On Apr 22, 2014, at 10:13 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
 On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com 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:
   my-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@apple.com/span
   /my-card
 
 Suppose this element's shadow DOM looks like this:
 Name: content select=.name/content
 Email: content select=.email/content
 
 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:
   my-card
 !-- shadow root begin --
 Name: content select=.name
   !-- distribution begin --
   span class=nameRyosuke Niwa/span
   !-- distribution end --
 /content
 Email: content select=.email
   !-- distribution begin --
   span class=emailrn...@apple.com/span
   !-- distribution end --
   /content
 !-- shadow root end --
   /my-card
 
 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:
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow
 
 If I had an instance of my-webkitten-card as follows:
   my-webkitten-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@webkit.org/span
   /my-webkitten-card
 
 Then its composed tree will look like this:
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
   shadow
   !-- my-card's shadow root begin --
   Name: content select=.name
 !-- distribution begin --
 span class=nameWebKitten/span
 span class=nameRyosuke Niwa/span
 !-- distribution end --
   /content
   Email: content select=.email
 !-- distribution begin --
 span class=emailrn...@webkit.org/span
 span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card
 
 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:
 
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
 shadow
   !-- my-card's shadow root begin --
   Name:
   content select=.name
 !-- distribution begin --
   span class=nameWebKitten/span
 !-- distribution end --
   /content
   Email:
   content select=.email
 !-- distribution begin --
   span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card
 
 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

2014-04-27 Thread Ryosuke Niwa
On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov dglaz...@chromium.org 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 dglaz...@chromium.org 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

2014-04-22 Thread Dimitri Glazkov
On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com 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:
   my-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@apple.com/span
   /my-card

 Suppose this element's shadow DOM looks like this:
 Name: content select=.name/content
 Email: content select=.email/content

 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:
   my-card
 !-- shadow root begin --
 Name: content select=.name
   !-- distribution begin --
   span class=nameRyosuke Niwa/span
   !-- distribution end --
 /content
 Email: content select=.email
   !-- distribution begin --
   span class=emailrn...@apple.com/span
   !-- distribution end --
   /content
 !-- shadow root end --
   /my-card

 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:
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow

 If I had an instance of my-webkitten-card as follows:
   my-webkitten-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@webkit.org/span
   /my-webkitten-card

 Then its composed tree will look like this:
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
   shadow
   !-- my-card's shadow root begin --
   Name: content select=.name
 !-- distribution begin --
 span class=nameWebKitten/span
 span class=nameRyosuke Niwa/span
 !-- distribution end --
   /content
   Email: content select=.email
 !-- distribution begin --
 span class=emailrn...@webkit.org/span
 span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card

 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:

   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
 shadow
   !-- my-card's shadow root begin --
   Name:
   content select=.name
 !-- distribution begin --
   span class=nameWebKitten/span
 !-- distribution end --
   /content
   Email:
   content select=.email
 !-- distribution begin --
   span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card


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: Separating Transclusion Mechanisms for Inheritance and Data Binding

2014-04-22 Thread Dimitri Glazkov
On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com 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:
   my-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@apple.com/span
   /my-card

 Suppose this element's shadow DOM looks like this:
 Name: content select=.name/content
 Email: content select=.email/content

 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:
   my-card
 !-- shadow root begin --
 Name: content select=.name
   !-- distribution begin --
   span class=nameRyosuke Niwa/span
   !-- distribution end --
 /content
 Email: content select=.email
   !-- distribution begin --
   span class=emailrn...@apple.com/span
   !-- distribution end --
   /content
 !-- shadow root end --
   /my-card

 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:
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow

 If I had an instance of my-webkitten-card as follows:
   my-webkitten-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@webkit.org/span
   /my-webkitten-card

 Then its composed tree will look like this:
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
   shadow
   !-- my-card's shadow root begin --
   Name: content select=.name
 !-- distribution begin --
 span class=nameWebKitten/span
 span class=nameRyosuke Niwa/span
 !-- distribution end --
   /content
   Email: content select=.email
 !-- distribution begin --
 span class=emailrn...@webkit.org/span
 span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card

 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:

   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
 shadow
   !-- my-card's shadow root begin --
   Name:
   content select=.name
 !-- distribution begin --
   span class=nameWebKitten/span
 !-- distribution end --
   /content
   Email:
   content select=.email
 !-- distribution begin --
   span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card

 *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 %}
 section class=left  {% block left %}{% endblock %}/section
 section class=right  {% block right %}  This is more content  {% endblock 
 %}/section

 And we render this template:

 {% extends parent.html %}
 {% block left %}This is the left side!{% endblock %}
 {% block right

Re: Separating Transclusion Mechanisms for Inheritance and Data Binding

2014-04-22 Thread Dimitri Glazkov
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

2014-04-22 Thread Dimitri Glazkov
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 dglaz...@chromium.orgwrote:

 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

2014-04-22 Thread Erik Bryn
*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 dglaz...@chromium.orgwrote:

 BTW, here's a jsbin that implements yield/transclude using existing Shadow
 DOM plumbing:

 http://jsbin.com/pacim/1/edit

 :DG



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

2014-04-21 Thread Hayato Ito
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 shadow are simply *ignored*.
Therefore, I'm afraid that a shadow tree for my-webkitten-card:

  shadow
span class=nameWebKitten/span
content/content
span class=emailkit...@webkit.org/span
  /shadow

doesn't make sense here. That would be equivalent with a
shadow/shadow.

Does it have any affect for your proposal?



On Thu, Apr 17, 2014 at 6:43 PM, Ryosuke Niwa rn...@apple.com wrote:

 Sorry, I forgot to add [Shadow DOM] in the title.

 On Apr 17, 2014, at 2:42 AM, Ryosuke Niwa rn...@apple.com 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:
   my-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@apple.com/span
   /my-card

 Suppose this element's shadow DOM looks like this:
 Name: content select=.name/content
 Email: content select=.email/content

 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:
   my-card
 !-- shadow root begin --
 Name: content select=.name
   !-- distribution begin --
   span class=nameRyosuke Niwa/span
   !-- distribution end --
 /content
 Email: content select=.email
   !-- distribution begin --
   span class=emailrn...@apple.com/span
   !-- distribution end --
   /content
 !-- shadow root end --
   /my-card

 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:
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow

 If I had an instance of my-webkitten-card as follows:
   my-webkitten-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@webkit.org/span
   /my-webkitten-card

 Then its composed tree will look like this:
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
   shadow
   !-- my-card's shadow root begin --
   Name: content select=.name
 !-- distribution begin --
 span class=nameWebKitten/span
 span class=nameRyosuke Niwa/span
 !-- distribution end --
   /content
   Email: content select=.email
 !-- distribution begin --
 span class=emailrn...@webkit.org/span
 span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card

 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:

   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
 shadow
   !-- my-card's shadow root begin --
   Name:
   content select=.name
 !-- distribution begin --
   span class=nameWebKitten/span
 !-- distribution end --
   /content
   Email:
   content select=.email
 !-- distribution begin --
   span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card

 *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

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

2014-04-21 Thread Ryosuke Niwa
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 hay...@chromium.org 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 shadow are simply *ignored*. 
 Therefore, I'm afraid that a shadow tree for my-webkitten-card:
 
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow
 
 doesn't make sense here. That would be equivalent with a shadow/shadow.
 
 Does it have any affect for your proposal?
 
 
 
 On Thu, Apr 17, 2014 at 6:43 PM, Ryosuke Niwa rn...@apple.com wrote:
 Sorry, I forgot to add [Shadow DOM] in the title.
 
 On Apr 17, 2014, at 2:42 AM, Ryosuke Niwa rn...@apple.com 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:
   my-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@apple.com/span
   /my-card
 
 Suppose this element's shadow DOM looks like this:
 Name: content select=.name/content
 Email: content select=.email/content
 
 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:
   my-card
 !-- shadow root begin --
 Name: content select=.name
   !-- distribution begin --
   span class=nameRyosuke Niwa/span
   !-- distribution end --
 /content
 Email: content select=.email
   !-- distribution begin --
   span class=emailrn...@apple.com/span
   !-- distribution end --
   /content
 !-- shadow root end --
   /my-card
 
 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:
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow
 
 If I had an instance of my-webkitten-card as follows:
   my-webkitten-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@webkit.org/span
   /my-webkitten-card
 
 Then its composed tree will look like this:
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
   shadow
   !-- my-card's shadow root begin --
   Name: content select=.name
 !-- distribution begin --
 span class=nameWebKitten/span
 span class=nameRyosuke Niwa/span
 !-- distribution end --
   /content
   Email: content select=.email
 !-- distribution begin --
 span class=emailrn...@webkit.org/span
 span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card
 
 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:
 
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
 shadow
   !-- my-card's shadow root begin --
   Name:
   content select=.name
 !-- distribution begin --
   span class=nameWebKitten/span
 !-- distribution end --
   /content
   Email:
   content select=.email
 !-- distribution begin --
   span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card
 
 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

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

2014-04-21 Thread William Chen
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=nameNon-random Distribution/span
content select=.pickme/content
/shadow

light dom:
random-element
span class=nameThis will not be distributed to the older
shadow./span
span class=pickmeThis 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


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

2014-04-21 Thread Ryosuke Niwa
On Apr 21, 2014, at 4:36 PM, William Chen wc...@mozilla.com 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 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.

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 shadow 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):
 content select=.name/content
 content select=.pickme/content
 
 younger shadow root (subclass):
 shadow
 span class=nameNon-random Distribution/span
 content select=.pickme/content
 /shadow
 
 light dom:
 random-element
 span class=nameThis will not be distributed to the older 
 shadow./span
 span class=pickmeThis 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.

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