Re: Inheritance Model for Shadow DOM Revisited

Could you help me to understand what "implicitly" means here?

In this particular case, you might want to blame the super class's author
and tell the author, "Please use <content select=.input-foo> so that
subclass can override it with arbitrary element with class="input-foo".

Could you give me an concrete example which <content slot> can support, but
"<shadow> as function" can't support?


On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Apr 27, 2015, at 9:50 PM, Hayato Ito <hayato@chromium.org> wrote:
> >
> > 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.
>
> We're (and consequently I'm) fully aware of that feature/prosal, and we
> still don't think it adequately addresses the needs of subclassing.
>
> The problem with "<shadow> as function" is that the superclass implicitly
> selects nodes based on a CSS selector so unless the nodes a subclass wants
> to insert matches exactly what the author of superclass considered, the
> subclass won't be able to override it. e.g. if the superclass had an
> insertion point with select="input.foo", then it's not possible for a
> subclass to then override it with, for example, an input element wrapped in
> a span.
>
> > 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.
>
> I'm not even arguing about the implementation difficulty. I'm saying that
> the semantics is inadequate for subclassing.
>
> - R. Niwa
>
>