Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

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 <> wrote:

> On Dec 5, 2013, at 10:09 PM, Hajime Morrita <> 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


Received on Friday, 6 December 2013 06:45:17 UTC