Re: Inheritance Model for Shadow DOM Revisited

> On Apr 30, 2015, at 2:29 PM, Brian Kardell <bkardell@gmail.com> wrote:
> 
> On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 
>>> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> 
>>> On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>>> 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.
>>> 
>>> So what if we flipped this as well and came up with an imperative API
>>> for "<shadow> as a function". I.e. "<shadow> as an actual function"?
>>> Would that give us agreement?
>> 
>> We object on the basis that "<shadow> as a function" is fundamentally backwards way of doing the inheritance.  If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView.  It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView.  That's has-a relationship which is appropriate for composition.
> 
> 
> Is there really a hard need for inheritance over composition? Won't
> composition ability + an imperative API that allows you to properly
> delegate to the stuff you contain be just fine for a v1?

Per resolutions in F2F last Friday, this is a discussion for v2 since we're definitely not adding multiple generations of shadow DOM in v1.

However, we should have a sound plan for inheritance in v2 and make sure our imperative API is forward compatible with it. So the goal here is to come up with some plan for inheritance so that we can be confident that our inheritance API is not completely busted.

- R. Niwa

Received on Thursday, 30 April 2015 21:44:38 UTC