W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Inheritance Model for Shadow DOM Revisited

From: Ryosuke Niwa <rniwa@apple.com>
Date: Fri, 01 May 2015 01:36:00 -0700
Cc: Hayato Ito <hayato@chromium.org>, WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
Message-id: <28367356-3DB7-4ED4-91E4-A6BCA43C1F54@apple.com>
To: Anne van Kesteren <annevk@annevk.nl>

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:56 UTC