W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2013

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

From: Hajime Morrita <morrita@google.com>
Date: Fri, 6 Dec 2013 15:44:49 +0900
Message-ID: <CALzNm5pcTaXo7TdUAE6wie0B_a8zBdNPMme0yvz0OBK0F8-zbw@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:20 UTC