- From: Dominic Cooney <dominicc@google.com>
- Date: Sun, 8 Dec 2013 09:38:41 +0900
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Hajime Morrita <morrita@google.com>, Dimitri Glazkov <dglazkov@chromium.org>, "public-webapps@w3.org WG" <public-webapps@w3.org>, Jan Miksovsky <jan@quickui.org>
- Message-ID: <CAHnmYQ_mC33Sdi1FnTH9n7CnYq5P__MFAaZvzA-J9t6vFAXWag@mail.gmail.com>
On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa <rniwa@apple.com> wrote: > On Dec 5, 2013, at 10:09 PM, Hajime Morrita <morrita@google.com> wrote: > > On inheritance around HTMLElement family, there seems to be a confusion > between interface side inheritance and implementation side inheritance. > > Right. Differentiating the two is very important. > > > For Custom Elements, the inheritance is not only about interface, but > also about implementation. The implementation is more complex and flux in > detail, thus worth being shared between different elements. Actually, the > implementation of built-in HTML elements, which are usually done in C++, > uses inheritance heavily, at least Blink and (I believe) WebKit. > > The reason we can use inheritance heavily is because we have control over > both parent and child classes, and there are careful distinctions between > public, protected, and private member functions and member variables in > those classes. > > Unfortunately, custom elements can't easily inherit from these builtin > HTML elements because builtin elements do not provide "protected" > functions, and they don't expose necessary hooks to override internal > member functions to modify behaviors. > Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. > Evidently, in the current Custom Elements specification, the interface is > inherited but the implementation (DOM) is composed via shadow element. > There is a lot more to the implementation of an element than what is in its Shadow DOM. By analogy, Blink has lots of C++ code implementing built-in elements and relatively few of them have Shadow DOM. It is also incorrect to think all elements have Shadow DOM. > In fact, we've come to a conclusion that shadow element is an unnecessary > complexity because composition is the preferred mechanism to build complex > objects on the Web, and if someone is using inheritance, then the subclass > should have access to the shadow DOM of the superclass directly instead of > it being magically projected into the shadow element. In fact, this is how > inheritance works in other GUI frameworks such as Cocoa, .net, etc… > > Additionally, we don't have something like shadow element inside Blink or > WebKit for our builtin elements. If our goal is to explain and describe > the existing features on the Web platform, then we sure shouldn't be > introducing this magical mechanism. > > If we had a subclass that truly wanted to contain its superclass in some > non-trivial fashion, then we should be using composition instead. If the > container class needed to forward some method calls and property accesses > to the contained element, then it should just do. And providing a > convenient mechanism to forward method calls and property access in > JavaScript is an orthogonal problem we should be solving anyway. > > - R. Niwa > > > -- <http://goto.google.com/dc-email-sla>
Received on Sunday, 8 December 2013 00:39:11 UTC