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 <> wrote:

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

Reply via email to