On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page <wilsonpage@me.com> wrote:
> This is an interesting approach that didn't occur to me! Similar to Anne's
> concerns, this would require you to have more knowledge of the internals of
> the super-class component. If you own both components then this is fine.
>
Yes, the main problem here is the degree of separation between creator and
consumer of the base component. The higher the degree, the less inclined
the creator will be to expose innards of the shadow tree to the consumer.
Multiple shadow roots solves the same problem as shadow trees (provides a
composition contract), but along the inheritance chain.
For example, multiple shadow roots make sense:
* if you are a maker of UI library that's strongly rooted in inheritance
and intend to for your base components to be used directly;
* if you are hoping to inherit from components with closed shadow trees.
> Also if this means we can remove a complex piece from the spec to help
> reach consensus, great! :)
>
Whatever it takes.
:DG<