- From: <bugzilla@jessica.w3.org>
- Date: Fri, 15 Nov 2013 00:54:31 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23808 Dominic Cooney <dominicc@chromium.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dominicc@chromium.org --- Comment #1 from Dominic Cooney <dominicc@chromium.org> --- (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? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 15 November 2013 00:54:32 UTC