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

On inheritance around HTMLElement family, there seems to be a confusion
between interface side inheritance and implementation side inheritance.

In WebIDL, interfaces of HTML elements have inherited only from HTMLElement
interface. This is fine just because it cares only about interface (API
signature) but not about
implementation. Even though there are some duplication on API surface of
these elements, we can live with it as it is relatively stable and we have
other reuse mechanisms like
partial interface.

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.




On Fri, Dec 6, 2013 at 2:53 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Dec 5, 2013, at 9:30 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>
> On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
>> On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov <dglazkov@chromium.org>
>> wrote:
>>
>> On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>>> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov <dglazkov@chromium.org>
>>> wrote:
>>> > 3) The approach pollutes global name space with constructors. This had
>>> been voiced many times as unacceptable by developers.
>>> >
>>> > 4) How does build a custom element that uses <name-card> as its base
>>> element? What about <div> or any other HTML element?
>>> >
>>> > The last one remains to be the hardest. The tortured inheritance
>>> support is what killed <element> in the first place. We can't ignore the
>>> inheritance, since it is clearly present, in both DOM and JS. If we attempt
>>> to punt on supporting it, our decisions cut off the opportunities to evolve
>>> this right in the future, and will likely leave us with boogers like
>>> multiple syntaxes for inheritance vs. non-inheritance use cases.
>>>
>>> What exactly are you referring to by inheritance support?
>>
>>
>>> Inheritance from all builtin elements (e.g. subclasses of HTMLElement)?
>>>
>>> Or inheritance from custom elements authors have defined?
>>>
>>
>> Sure, both are fine. Why should we treat them differently?
>>
>>
>> For the following reasons to list a few:
>>
>>    1. We don't have any subclass of HTMLElement that can be instantiated
>>    and has subclasses.
>>
>> Not sure why this matters?
>
>
> It means that inheritance is NOT integral part of the platform; at least
> for builtin elements.
>
>
>>    1. Methods and properties of builtin elements are not designed to be
>>    overridden by subclasses.
>>
>> Okay, that seems like an implementation detail of HTML. Again, doesn't
> preclude seeking consistency between inheritance from custom elements or
> HTML elements.
>
>
> That's not an implementation detail.   The key observation is that HTML
> elements aren't designed to be subclassed.
>
>
>>    1. Behaviors of builtin elements will be changed by UAs in the future
>>    without author-defined subclasses being "upgraded" accordingly, thereby
>>    violating Liskov substitution principle.
>>
>> Sure, it's probably a bad idea to inherit from any HTML element (other
> than HTMElement).
>
>
> Great, then let's not support that.
>
> The Custom Elements spec is deeply steeped in the idea that we bring new
> functionality by explaining how the platform works (see
> http://extensiblewebmanifesto.org/). If we just side-load some new
> platform magic to accommodate a few specific use cases, we're not doing the
> right thing.
>
>
> Without getting into a philosophical debate, supporting inheritance from
> subclasses of HTML elements doesn't explain how the Web platform works at
> all so let's not add that.
>
> If we removed this, we don't have to worry about attaching shadow DOM to
> builtin elements (other than HTMLElement itself) for custom elements.
>
> - R. Niwa
>
>


-- 
morrita