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

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