> 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.
> On Apr 28, 2015, at 10:34 AM, Hayato Ito <hay...@chromium.org> wrote: > > Could you help me to understand what "implicitly" means here? I mean that the superclass’ insertion points use a CSS selector to select nodes to distribute. As a result, unless the subclass can supply the exactly kinds of nodes that matches the CSS selector, it won’t be able to override the contents into the insertion point. > 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”. The problem is that it may not be possible to coordinate across class hierarchy like that if the superclass was defined in a third party library. With the named slot approach, superclass only specifies the name of a slot, so subclass will be able to override it with whatever element it supplies as needed. > Could you give me an concrete example which <content slot> can support, but > "<shadow> as function" can't support? The problem isn’t so much that slot can do something "<shadow> as function" can’t support. It’s that "<shadow> as function" promotes over specification of what element can get into its insertion points by the virtue of using a CSS selector. Now, it's possible that we can encourage authors to always use a class name in select attribute to support this use case. But then why are we adding a capability that we then discourage authors from using it. - R. Niwa
