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

Consider standard conform button usage #20

Closed
Jamtis opened this issue Mar 20, 2016 · 3 comments
Closed

Consider standard conform button usage #20

Jamtis opened this issue Mar 20, 2016 · 3 comments

Comments

@Jamtis
Copy link

Jamtis commented Mar 20, 2016

Officially <button> elements should only have "phrasing content" as stated in the MDN and in the W3C draft.

I think it's a longterm goal to use all native elements in a standardized way.

I came across this problem when I tried to compile <basic-arrow-direction> with kangax' htmlmin@1.3.0 (see kangax/html-minifier#565) which broke the code.

What's your opinion about replacing invalid buttons in the future?

@JanMiksovsky
Copy link
Member

I don't believe it's the case that buttons can only contain phrasing content. At least one spec for the button element indicates that buttons can support for a broader variety of content types, including flow content.

In any event, it's clear that buttons should be able to contain custom elements. Generally speaking, I would think that a tool that processes HTML should permit the inclusion of custom elements anywhere.

To help answer the question about how tools like html-minifier should handle custom elements, I've raised this as a question on w3c/webcomponents.

@Jamtis
Copy link
Author

Jamtis commented Mar 23, 2016

Appreciate the effort.

@JanMiksovsky
Copy link
Member

The latest spec indicates that custom elements can be used "where phrasing content is expected".

So I think HTML tools like htmlmin should be extended to support the use of custom elements inside of elements like <button>. You could file an issue on htmlmin and point at the new spec.

Many thanks for raising the original issue so that this could get officially resolved in a W3C spec. I don't think there's anything more for me to do here, so I'm going to close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants