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

On Dec 10, 2013, at 12:24 PM, Elliott Sprehn <esprehn@chromium.org> wrote:

> 
> On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 12/10/13 10:34 AM, Anne van Kesteren wrote:
> >> E.g. the <dialog>'s close() method won't work as defined
> >> right now on a subclass of HTMLDialogElement.
> >
> > Why not?
> >
> > I assumed that actual ES6 subclassing, complete with invoking the right
> > superclass @@create, would in fact produce an object for which this would
> > work correctly.  At least any situation that doesn't lead to that is a
> > UA/spec bug.
> 
> Well for one because the specification at the moment talks about a
> <dialog> element and does not consider the case where it may have been
> subclassed. The "pending dialog stack" is also for <dialog> elements
> only, not exposed in any way, etc. The way the platform is set up at
> the moment is very defensive and not very extensible.
> 
> 
> When extending native elements like that you use type extensions, so it'd be <dialog is="my-subclass"> and the tagName is still DIALOG. Registering something that extends HTMLDialogElement but isn't a type extension of "dialog" does not work, in the same way that doing __proto__ = HTMLDivElement doesn't magically make you into a <div> today.

The document.register method does not seem to support what you describe as currently spec'd, but does have an API doing the thing that won't actually work, i.e. registering <my-subclass> to be a subclass of HTMLDialogElement.

Regards,
Maciej