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 <rn...@apple.com> wrote: > > > On Apr 27, 2015, at 9:50 PM, Hayato Ito <hay...@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 > >
