21888 2013-05-01 04:42:49 +0000 [Custom]: #dfn-custom-element-definition should be defined, and maybe registering a type extension of a custom tag should become an error? 2013-05-21 22:21:11 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED FIXED P2 normal --- 18720 1 dominicc dglazkov public-webapps-bugzilla oldest_to_newest 87062 0 dominicc 2013-05-01 04:42:49 +0000 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(). 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.") 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. 87379 1 dglazkov 2013-05-07 21:12:16 +0000 (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? 87380 2 dglazkov 2013-05-07 21:16:28 +0000 Fixed up links in https://dvcs.w3.org/hg/webcomponents/rev/a585db092558. 87395 3 dominicc 2013-05-08 00:06:31 +0000 (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? 88031 4 dglazkov 2013-05-21 22:21:11 +0000 I think I clarified this in https://dvcs.w3.org/hg/webcomponents/rev/ea07a8c6329c. Please let me know if this still smells.