From: Boris Zbarsky [mailto:bzbar...@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.
