Note: Our current consensus is to defer this until v2.

> On Apr 27, 2015, at 9:09 PM, Hayato Ito <> 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 

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 

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:

    <style>subclass styles go here</style>

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.

[2] Polymer’s core- elements, Polymer’s paper- elements, and the Basic Web 
Components’ collection of basic- elements

- R. Niwa

Reply via email to