Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Custom]: A tag name should be associated with the constructor and not the prototype (bugzilla: 24020) #214

Closed
hayatoito opened this issue Jul 6, 2015 · 1 comment

Comments

@hayatoito
Copy link
Contributor

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)

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.

@rniwa
Copy link
Collaborator

rniwa commented Mar 1, 2016

This problem will be resolved in the issues #365 and #403.

@rniwa rniwa closed this as completed Mar 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants