(In reply to comment #0)
> This bookmark "#dfn-custom-element-definition" is referred to from Step 1 of
> the element initialization algorithm but does not seem to be defined
> anywhere.
> 
> What I'm trying to close in on is a simplification of the spec.
> Specifically, there's an asymmetry between document.register, which seems to
> admit setting up a type extension of a custom tag, for example:
> 
> XA = document.register('x-a');
> XB = document.register('x-b', {prototype: XA.prototype});
> 
> and createElement/parsing which says that:
> 
> "After a custom element is instantiated, changing the value of the is
> attribute must not affect this element's custom element name.
> 
> If both types of custom element names are provided at the time of element's
> instantiation, the custom tag must win over the type extension."
> 
> I'm specifically worried about the difference in meaning between parsing
> <x-a is="x-b"></x-a> and simply calling new XB().

In <x-a is="x-b">, the "is" value is simply ignored. It has no meaning, right (since the custom tag won)?

> 
> For example, could this create a constructor XB that is almost an alias of
> XA, but has subtly different lifecycle callbacks?
> 
> p = Object.create(HTMLElement.prototype, {
>   readyCallback: {value: t}
> });
> XA = document.register('x-a', {prototype: p});
> XA.prototype.readyCallback = u;
> XB = document.register('x-b', {prototype: XA.prototype});
> 
> Then:
> 
>   document.body.innerHTML = '<x-a></x-a>'
> 
> will call t. This is unsurprising.
> 
>   document.createElement('x-a', 'x-b')
> 
> will call t (because "If both types of custom element names are provided at
> the time of element's instantiation, the custom tag must win over the type
> extension.")

Yes, because the author simply created an instance of XA here. The "is" value is ignored.

> 
>   new XB()
> 
> may call u, or t, depending on what the meaning of "Let DEFINITION be
> ELEMENT's definition" (from the element initialization algorithm) is.
> 
> It seems extending a custom tag with another custom tag is reasonably well
> defined. Similarly, extending a type extension with another type extension
> squirrels up the prototype chain past the parent type extension to a
> built-in interface which isn't complicated with lifecycle callbacks. 
> 
> But extending a custom tag with a type extension begets ambiguity. I think
> it should be disallowed. I think that is what the intent of "If both types
> of custom element names are provided at the time of element's instantiation,
> the custom tag must win over the type extension" is, but the generated
> constructor is a loophole.

I don't see where there's ambiguity. You simply can't use "is" with a custom tag. Can you help me understand better where the problem is?

Fixed up links in https://dvcs.w3.org/hg/webcomponents/rev/a585db092558.

(In reply to comment #1)
> (In reply to comment #0)
> I don't see where there's ambiguity. You simply can't use "is" with a custom
> tag. Can you help me understand better where the problem is?

Let me try again--sorry that was a bit of a ramble.

I think I was confused by the document.register steps.

If an author writes this code:

1: var A = document.register('x-a');
2: var B = document.register('x-b', {prototype: Object.create(A.prototype)});

Then on line 2, after register step 5.2, is INTERFACE going to be A or HTMLElement?

I think I clarified this in https://dvcs.w3.org/hg/webcomponents/rev/ea07a8c6329c.

Please let me know if this still smells.