You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given how WebIdl works with interfaces that are realized as ES constructor functions with a prototype we should associate the tag name with a function and not the prototype.
class MyElement extends HTMLElement {}
associate('my-element, MyElement)
When an element is created for 'my-element' we find the registered Function and call its @@create-(this-is-inserted-to-avoid-notification-in-migration). Here is how HTMLElement @@create-(this-is-inserted-to-avoid-notification-in-migration) is implemented.
var constructorToNameMap = new WeakMap();
function associate(name, constr) {
constructorToNameMap.set(constr, name);
}
HTMLElement[Symbol.create] = function() {
var name = constructorToNameMap.get(this);
if (!name)
throw new TypeError('Illegal constructor');
The common case is that people do not override @@create-(this-is-inserted-to-avoid-notification-in-migration) so we do not need to run any user code to create an instance. When the user does a new MyElement we do run the constructor, just like for all other js constructors.
I think this should be addressed in Level 2 of the Custom Elements spec, or in a related spec. Chrome is not in a position to implement this now.
The current implementation in Chrome associates the registered element name with the generated constructor. This is effectively the same data as the constructorToNameMap. So I think Chrome would have no problem implementing requirements based on your proposal.
I do not think the specification needs to be as literal as the JavaScript you have provided here, but it is a good informative sketch.
I think that the requirement that registering a Custom Element with a prototype that is an interface prototype object should be relaxed to allow multiple element names to share a prototype as is the case with built-in elements like HTMLHeadingElement, etc. Perhaps misuse of a built-in interface prototype object should be disallowed, however Chrome would not have a problem with a completely laissez-faire approach.
Relaxing the interface prototype object restriction would be a forward-compatible change because it makes errors into non-errors.
I am trying to work out what is the significance of storing constructor, rather than prototype in custom element definition. Can you help me understand that?
I think this is mostly conceptual since we are locking down the prototype and constructor properties so we can go back and forth as needed.
However, ES/WebIDL works with Functions and ES6 has meta operations for creating new objects from a constructor, not from its prototype (since the prototype does not have any relevance to how the instance is created).
I think this is mostly conceptual since we are locking down the prototype
and constructor properties so we can go back and forth as needed.
However, ES/WebIDL works with Functions and ES6 has meta operations for
creating new objects from a constructor, not from its prototype (since the
prototype does not have any relevance to how the instance is created).
Title: [Custom]: A tag name should be associated with the constructor and not the prototype (bugzilla: 24020)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24020
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24020#c0
Erik Arvidsson wrote on 2013-12-06 15:58:32 +0000.
Given how WebIdl works with interfaces that are realized as ES constructor functions with a prototype we should associate the tag name with a function and not the prototype.
class MyElement extends HTMLElement {}
associate('my-element, MyElement)
When an element is created for 'my-element' we find the registered Function and call its @@create-(this-is-inserted-to-avoid-notification-in-migration). Here is how HTMLElement @@create-(this-is-inserted-to-avoid-notification-in-migration) is implemented.
var constructorToNameMap = new WeakMap();
function associate(name, constr) {
constructorToNameMap.set(constr, name);
}
HTMLElement[Symbol.create] = function() {
var name = constructorToNameMap.get(this);
if (!name)
throw new TypeError('Illegal constructor');
// $Internal_createElementWithName(name);
return document.createElement(name);
};
The common case is that people do not override @@create-(this-is-inserted-to-avoid-notification-in-migration) so we do not need to run any user code to create an instance. When the user does a
new MyElement
we do run the constructor, just like for all other js constructors.comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24020#c1
Dominic Cooney wrote on 2013-12-08 00:32:29 +0000.
I think this should be addressed in Level 2 of the Custom Elements spec, or in a related spec. Chrome is not in a position to implement this now.
The current implementation in Chrome associates the registered element name with the generated constructor. This is effectively the same data as the constructorToNameMap. So I think Chrome would have no problem implementing requirements based on your proposal.
I do not think the specification needs to be as literal as the JavaScript you have provided here, but it is a good informative sketch.
I think that the requirement that registering a Custom Element with a prototype that is an interface prototype object should be relaxed to allow multiple element names to share a prototype as is the case with built-in elements like HTMLHeadingElement, etc. Perhaps misuse of a built-in interface prototype object should be disallowed, however Chrome would not have a problem with a completely laissez-faire approach.
Relaxing the interface prototype object restriction would be a forward-compatible change because it makes errors into non-errors.
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24020#c2
Dimitri Glazkov wrote on 2014-05-12 22:08:11 +0000.
I am trying to work out what is the significance of storing constructor, rather than prototype in custom element definition. Can you help me understand that?
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24020#c3
Erik Arvidsson wrote on 2014-05-13 13:56:04 +0000.
I think this is mostly conceptual since we are locking down the prototype and constructor properties so we can go back and forth as needed.
However, ES/WebIDL works with Functions and ES6 has meta operations for creating new objects from a constructor, not from its prototype (since the prototype does not have any relevance to how the instance is created).
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-createfromconstructor
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24020#c4
Dimitri Glazkov wrote on 2014-05-13 14:22:28 +0000.
(In reply to Erik Arvidsson from comment #3)
Ah! That makes sense. I will leave the bug open and block it on bug 25669.
The text was updated successfully, but these errors were encountered: