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

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

Received on Friday, 6 December 2013 06:35:12 UTC