- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 1 May 2015 18:37:21 +0200
- 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. -- https://annevankesteren.nl/
Received on Friday, 1 May 2015 16:37:45 UTC