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

Add a developer-facing note explaining why is="" is necessary #147

Closed
hayatoito opened this issue Jul 6, 2015 · 0 comments
Closed

Add a developer-facing note explaining why is="" is necessary #147

hayatoito opened this issue Jul 6, 2015 · 0 comments

Comments

@hayatoito
Copy link
Contributor

Title: [Custom]: type extensions should be available as custom tags, not only through (bugzilla: 27976)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27976


comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27976#c0
Randy Harmon wrote on 2015-02-07 18:52:01 +0000.

It seems to me that it's unnecessarily limiting to require that users specify the base tag type and also the extension tag. It seems to prevent the direct use of semantic tags which happen to use a non-generic html tag prototype.

This might be simply a clarity issue, where in 11.2 Type Extension Example, you could specify that is equivalent to .


comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27976#c1
Boris Zbarsky wrote on 2015-02-07 21:44:19 +0000.

If you want the HTML spec (and hence browsers) to think it's a button, you can't call it , because both the HTML spec and browser implementations are in terms of the localName of the element. So are browser extensions, various web libraries, and so forth.

This has been discussed at quite some length several times already. Doing this in a green-field design might have made sense, but at this point we're talking about boiling the ocean.


comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27976#c2
Randy Harmon wrote on 2015-02-08 21:25:05 +0000.

OK. Thanks for the info.

Seems worth an aside in the doc, just to clarify that for current compatibility reasons, a native element cannot be considered a native element by the browser if it is extended via is="".


comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27976#c3
Randy Harmon wrote on 2015-02-08 21:26:08 +0000.

s/cannot/can only/


comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27976#c4
markg wrote on 2015-02-19 03:48:52 +0000.

I have not seen this stated very explicitly anywhere. How about a note in the spec at someplace like this location:

http://w3c.github.io/webcomponents/spec/custom/#custom-tag-example

It might make it clear like this:

"If you want a custom element to extend a native element like

, then you cannot use a custom tag name for it. Instead, you must use the native element tagname with the @is-(this-is-inserted-to-avoid-notification-in-migration) attribute, something like . It will not work to use a custom tag such as to extend (HTMLButtonElement prototype).

"Saying it another way, custom tagnames can only be used when you are not extending a native element (other than the default HTMLElement)."

@domenic domenic changed the title [Custom]: type extensions should be available as custom tags, not only through <baseTag is="..."> (bugzilla: 27976) Add a developer-facing note explaining why is="" is necessary Mar 8, 2016
@domenic domenic added the v1 label Mar 8, 2016
@domenic domenic closed this as completed in 58015e4 Mar 8, 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