Inheritance Model for Shadow DOM Revisited

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

Received on Tuesday, 28 April 2015 04:33:57 UTC