Re: Inheritance Model for Shadow DOM Revisited

> On May 1, 2015, at 1:04 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
> On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> To start off, I can think of three major ways by which subclass wants to interact with its superclass:
>> 1. Replace what superclass shows entirely by its own content - e.g. grab the device context and draw everything by yourself.
> 
> So this requires either replacing or removing superclass' ShadowRoot.
> 
>> 2. Override parts of superclass' content - e.g. subclass overrides virtual functions superclass provided to draw parts of the component/view.
> 
> This is where you directly access superclass' ShadowRoot I assume and
> modify things?

In the named slot approach, these overridable parts will be exposed to subclasses as an overridable slot. In terms of an imperative API, it means that the superclass has a virtual method (probably with a symbol name) that can get overridden by a subclass. The default implementation of such a virtual method does nothing, and shows the fallback contents of the slot.

>> 3. Fill "holes" superclass provided - e.g. subclass implements abstract virtual functions superclass defined to delegate the work.
> 
> This is the part that looks like it might interact with distribution, no?

With the named slot approach, we can also model this is an abstract method on the superclass that a subclass must implement. The superclass' shadow DOM construction code then calls this function to "fill" the slot.

- R. Niwa

Received on Friday, 1 May 2015 08:36:29 UTC