On Dec 10, 2013, at 12:24 PM, Elliott Sprehn <espr...@chromium.org> wrote:
> > On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky <bzbar...@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