From: Boris Zbarsky [] 

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

Reply via email to