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="name">Ryosuke Niwa</span>
>   <span class="email">rn...@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="name">Ryosuke Niwa</span>
>       <!-- distribution end -->
>     </content>
>     Email: <content select=".email">
>       <!-- distribution begin -->
>       <span class="email">rn...@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="name">WebKitten</span>
>     <content></content>
>     <span class="email">kit...@webkit.org</span>
>   </shadow>
> 
> If I had an instance of my-webkitten-card as follows:
>   <my-webkitten-card>
>   <span class="name">Ryosuke Niwa</span>
>   <span class="email">rn...@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="name">WebKitten</span>
>         <span class="name">Ryosuke Niwa</span>
>         <!-- distribution end -->
>       </content>
>       Email: <content select=".email">
>         <!-- distribution begin -->
>         <span class="email">rn...@webkit.org</span>
>         <span class="email">kit...@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="name">WebKitten</span>
>         <!-- distribution end -->
>       </content>
>       Email:
>       <content select=".email">
>         <!-- distribution begin -->
>           <span class="email">kit...@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

Reply via email to