RE: Defining a constructor for Element and friends

From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 

> That said, I do have one question already: what does the term "own-instances" mean in that document?

Explained at the top:

"Terminology: In what follows I use 'own-instances of X' to mean objects where obj.constructor === X, as distance from 'instances of X' which means objects for which obj instanceof X."

>>> whether it is acceptable to have an element whose name is "a", 
>>> namespace is the HTML namespace, and interface is Element
>
> I'd like to understand what you mean by "interface is Element" here, exactly.

I'm just quoting Anne :). My interpretation is that the (object representing the) element is an own-instance of Element.

>>  From a naïve authoring point of view that seems suboptimal. I'd rather be able to do `class MyImg extends HTMLImageElement { constructor(document) { super(document); } }` and have MyImg instances treated specially by the platform in all the ways "img" currently is.
>
> I don't quite see the issue here.  Presumably the HTMLImageElement constructor passes "img" as the localName to the HTMLElement constructor, so your MyImg would get "img" as the localName, right?

Ah, right, of course. I am skipping a few steps and my steps are wrong, so my concern wasn't well-founded. My vision was that MyImg had local name my-img via some custom element stuff, as with the my-q example below. I agree that it works though as stated.

>> Or, for an easier example, I'd like to be able to do `class MyQ extends HTMLQuoteElement { constructor(document) { super(document); } }` and have `(new MyQ()).cite` actually work, instead of throw a "cite getter incompatible with MyQ" error because I didn't get the HTMLQuoteElement internal slots.
>
> This should totally work, of course.  Why wouldn't it, exactly?  Given the subclassing proposal on the table in ES6 right now, it would work splendidly, since the HTMLQuoteElement constructor is what would perform the object allocation and it would pass along "q" as the localName. 
> (Though actually, HTMLQuoteElement is excitingly complicated, because both <q> and <blockquote> would use that constructor, so it would need to either require one of those two strings be passed in, or default to "q" unless "blockquote" is passed in or something.)

Right, so I should have actually written `class MyQ extends HTMLQuoteElement { constructor(document) { super("q", document); } }`. My repo's .js file covers the case of HTMLQuoteElement specifically to illustrate how to deal with classes that cover more than one local name.

And yeah, I agree it works again.

The other stuff, which is really about custom elements, I'll spin off into a new thread.

Received on Sunday, 11 January 2015 19:34:12 UTC