- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Thu, 30 Apr 2015 14:35:29 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Hayato Ito <hayato@chromium.org>, WebApps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
> 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"? 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. 2. Override parts of superclass' content - e.g. subclass overrides virtual functions superclass provided to draw parts of the component/view. 3. Fill "holes" superclass provided - e.g. subclass implements abstract virtual functions superclass defined to delegate the work. - R. Niwa
Received on Thursday, 30 April 2015 21:35:58 UTC