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

Re: Inheritance Model for Shadow DOM Revisited

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 1 May 2015 18:37:21 +0200
Message-ID: <CADnb78jT_1eQCfh8HDCzESn2brNY2=ROZw921XkK=1KuN7Tmvw@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Hayato Ito <hayato@chromium.org>, WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
On Fri, May 1, 2015 at 10:36 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> On May 1, 2015, at 1:04 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> 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.

I think I need to see code in order to grasp this.

Received on Friday, 1 May 2015 16:37:45 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC