- 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