24020 2013-12-06 15:58:32 +0000 [Custom]: A tag name should be associated with the constructor and not the prototype 2015-07-06 08:16:49 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED MOVED P2 normal --- 25669 1 erik.arvidsson dglazkov dominicc public-webapps-bugzilla oldest_to_newest 97248 0 erik.arvidsson 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. Here is how HTMLElement @@create 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 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. 97287 1 dominicc 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. 105770 2 dglazkov 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? 105850 3 erik.arvidsson 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 105854 4 dglazkov 2014-05-13 14:22:28 +0000 (In reply to Erik Arvidsson from comment #3) > 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 Ah! That makes sense. I will leave the bug open and block it on bug 25669. 121748 5 hayato 2015-07-06 08:16:49 +0000 Moved to https://github.com/w3c/webcomponents/issues/214