Re: Inheritance Model for Shadow DOM Revisited

I'm aware that our consensus is to defer this until v2. Don't worry. :)

The feature of "<shadow> as function" supports *subclassing*. That's
exactly the motivation I've introduced it once in the spec (and implemented
it in blink).
I think Jan Miksovsky, co-author of Apple's proposal, knows well that.

The reason I reverted it from the spec (and the blink), [1], is a technical
difficulty to implement, though I've not proved that it's impossible to
implement.

[1] https://codereview.chromium.org/137993003


On Tue, Apr 28, 2015 at 1:33 PM Ryosuke Niwa <rniwa@apple.com> wrote:

> Note: Our current consensus is to defer this until v2.
>
> > On Apr 27, 2015, at 9:09 PM, Hayato Ito <hayato@chromium.org> wrote:
> >
> > For the record, I, as a spec editor, still think "Shadow Root hosts yet
> another Shadow Root" is the best idea among all ideas I've ever seen, with
> a "<shadow> as function", because it can explain everything in a unified
> way using a single tree of trees, without bringing yet another complexity
> such as multiple templates.
> >
> > Please see
> https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22
>
> That's a great mental model for multiple generations of shadow DOM but it
> doesn't solve any of the problems with API itself.  Like I've repeatedly
> stated in the past, the problem is the order of transclusion.  Quoting from
> [1],
>
> The `<shadow>` element is optimized for wrapping a base class, not filling
> it in. In practice, no subclass ever wants to wrap their base class with
> additional user interface elements. A subclass is a specialization of a
> base class, and specialization of UI generally means adding specialized
> elements in the middle of a component, not wrapping new elements outside
> some inherited core.
>
> In the three component libraries [1] described above, the only cases where
> a subclass uses `<shadow>` is if the subclass wants to add additional
> styling. That is, a subclass wants to override base class styling, and can
> do so via:
>
>   ```
>   <template>
>     <style>subclass styles go here</style>
>     <shadow></shadow>
>   </template>
>   ```
>
> One rare exception is `core-menu` [3], which does add some components in a
> wrapper around a `<shadow>`. However, even in that case, the components in
> question are instances of `<core-a11y-keys>`, a component which defines
> keyboard shortcuts. That is, the component is not using this wrapper
> ability to add visible user interface elements, so the general point stands.
>
> As with the above point, the fact that no practical component has need for
> this ability to wrap an older shadow tree suggests the design is solving a
> problem that does not, in fact, exist in practice.
>
>
> [1]
> https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
> [2] Polymer’s core- elements, Polymer’s paper- elements, and the Basic Web
> Components’ collection of basic- elements
> [3]
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FPolymer%2Fcore-menu%2Fblob%2Fmaster%2Fcore-menu.html&sa=D&sntz=1&usg=AFQjCNH0Rv14ENbplb6VYWFh8CsfVo9m_A
>
> - R. Niwa
>
>