- From: Hajime Morrita <morrita@google.com>
- Date: Fri, 6 Dec 2013 15:44:49 +0900
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Dimitri Glazkov <dglazkov@chromium.org>, "public-webapps@w3.org WG" <public-webapps@w3.org>, Jan Miksovsky <jan@quickui.org>
- Message-ID: <CALzNm5pcTaXo7TdUAE6wie0B_a8zBdNPMme0yvz0OBK0F8-zbw@mail.gmail.com>
I agree that it isn't trivial to inherit from a built-in element as if it is an author-defined element. My point was that mentioning relationship between HTMLElement and built-in elements on WebIDL doesn't matter in this discussion and we should focus on other reasoning. 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. > > Evidently, in the current Custom Elements specification, the interface is > inherited but the implementation (DOM) is composed via shadow element. > > 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 > > -- morrita
Received on Friday, 6 December 2013 06:45:17 UTC