This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It is not currently possible to always instantiate a custom element given just its name. Elements which derive from an existing HTML element must be instantiated with document.createElement(name,type), where type is the base HTML element. All other elements can be created via document.createElement(name). Unfortunately, this distinction means that, given just a name, it isn't possible to create an instance of a custom element. This presents a significant limitation on certain types of meta-elements that can take the name of *another* element and create instances of those. For example, see the thread at https://github.com/Polymer/polymer/issues/334#issuecomment-27610381, which discusses a custom element that renders a month calendar. For flexibility, this calendar element wants to accept the name of another element class that should be used to render the individual days in the calendar. That is, the calendar is a meta-element that wants to instantiate other elements (here, for the days). Such a meta-element cannot easily be constructed. Another common type of meta-element would be visual design tool which, given a list of element names, wants to be able to present a user interface that can create instantiates of those elements on demand. A meta-element could be designed to accept both a name ("my-button") and a base type ("button"), but this becomes cumbersome. Given just the name "my-button", it seems that it should be possible to do one or both of the following: 1) Invoke createElement("my-button") and get back a <button is="my-button">. 2) Have a facility that, given just an element name like "my-button", can look up its constructor or prototype. This would at least allow one to inspect the prototype chain and determine whether createElement(name) or createElement(name,type) is required. Alternatively, the facility could accept an element name and return the name of the element type it extends. The lack of such a facility is likely to force people to create custom elements that wrap a standard HTML element (i.e., include an instance in their template) rather than extend them, which would be an unfortunate limitation as the semantics are quite different.
(In reply to Jan Miksovsky from comment #0) > A meta-element could be designed to accept both a name ("my-button") and a > base type ("button"), but this becomes cumbersome. Given just the name > "my-button", it seems that it should be possible to do one or both of the > following: > 1) Invoke createElement("my-button") and get back a <button is="my-button">. Since Custom Element names are unique and don't overlap with element names, we could make createElement('x-foo') create x-foo even if it is <x-foo> or <button is="x-foo">. However this means if you register <button is="x-foo"> you can no longer create an <x-foo> element with createElement. This seems pernicious since if the definition is x-foo is not available at creation time, createElement('x-foo') will mint <x-foo>s which won't be upgraded. And after the definition is available, createElement will change its behavior. So I think this is a bad idea. > 2) Have a facility that, given just an element name like "my-button", can > look up its constructor or prototype. This would at least allow one to > inspect the prototype chain and determine whether createElement(name) or > createElement(name,type) is required. Alternatively, the facility could > accept an element name and return the name of the element type it extends. This sounds reasonable. It should include the built-in elements, I suppose? This might be something for the HTML spec?
Exposing the registry as an API sounds like a great Level 2 goal for the spec.