[Bug 21888] [Custom]: #dfn-custom-element-definition should be defined, and maybe registering a type extension of a custom tag should become an error?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21888

--- Comment #1 from Dimitri Glazkov <dglazkov@chromium.org> ---
(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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 7 May 2013 21:12:17 UTC