{"id":159789,"date":"2014-01-07T19:32:19","date_gmt":"2014-01-08T02:32:19","guid":{"rendered":"http:\/\/css-tricks.com\/?p=159789"},"modified":"2018-05-03T15:29:24","modified_gmt":"2018-05-03T22:29:24","slug":"use-button-element","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/use-button-element\/","title":{"rendered":"When To Use The Button Element"},"content":{"rendered":"

You use it when, uhm, you want a button on your page that users can click, right? Well, unfortunately it’s a bit more complicated than that. It’s not too bad though, let’s figure it out.<\/p>\n

<\/p>\n

It looks like this:<\/p>\n

<button>\r\n  Do Something\r\n<\/button><\/code><\/pre>\n
What’s the most common result of clicking something on a website? Moving to a new URL, like you would clicking a link (an <a href=\"\/example\/\"><\/a><\/code>) element).<\/p>\n
The <button><\/code> element, by itself, can’t do that. There have been various conversations<\/a> about allowing “href anywhere” over the years, but nothing has came of it.<\/p>\n
Clicking on a button does do something though, when used in its natural environment…<\/p>\n
Button is a Form Element<\/h3>\n
Web forms have submit buttons. You might think of that like this:<\/p>\n
<form action=\"\/\" method=\"post\">\r\n  <input type=\"submit\" value=\"Submit\">\r\n<\/form><\/code><\/pre>\n
A <button><\/code> element in a <form><\/code>, by default, behaves identically<\/strong> to that submit input above. <\/p>\n
<form action=\"\/\" method=\"post\">\r\n  <button>Submit<\/button>\r\n<\/form><\/code><\/pre>\n
However gross the UX, forms can have reset buttons as well. You can duplicate that behavior by changing the default submit type to reset.<\/p>\n
<form action=\"\/\" method=\"post\">\r\n  <button type=\"reset\">Reset<\/button>\r\n<\/form><\/code><\/pre>\n
Clicking that button will clear all the other inputs (and textareas) with the parent <form><\/code>.<\/p>\n
Buttons can have content<\/h3>\n
The primary reason for using a <button><\/code> is that it has both an opening and closing (<\/button><\/code>) tag. Which means there can be stuff<\/em> inside. A common use case would be something like:<\/p>\n
<button>\r\n  <img src=\"tiny_birthday_cake.png\" alt=\"\">\r\n  Submit\r\n<\/button><\/code><\/pre>\n
While an input can be <input type=\"image\"><\/code>, this mixed content would be hard to pull off. <\/p>\n
You can probably get away with putting just any HTML inside a button, but MDN points out<\/a> the “permitted content” of a button is limited to “phrasing content”<\/a>. Phrasing content is a limited subset of HTML elements that “defines the text and the mark-up it contains. Runs of phrasing content make up paragraphs.”<\/p>\n
Pseudo elements<\/a> can be used too. <\/p>\n
Let’s leave styling <button><\/code>s for another day, but different browsers generally have a special style they apply to buttons. You’ll want to either leave that alone so the default comes through or remove it thoroughly so your new styling can be consistent across browsers.<\/p>\n
Let’s consider: “if a button doesn’t have a meaningful href, it\u2019s a <button>”<\/h3>\n
I said recently that I enjoyed<\/a> that sentiment. That’s what kicked off this article for me. At the time, I was thinking of how I enjoyed the semantics of it. As in:<\/p>\n
<a href=\"#0\">\r\n  I'm kinda sick of doing this for buttons.\r\n<\/a><\/code><\/pre>\n
There is no meaningful href there. The 0 is just there so it doesn’t jump the page, because ID’s can’t start with a number<\/a>. <\/p>\n
Chances are, HTML like the above means: I’m going to make clicking that do something with JavaScript.<\/em> Somehow that feels better than a <div><\/code> whatever, because you get the cursor change and whatever else default styles.<\/p>\n
If you don’t like those meaningless href’s, a <button><\/code> can seem like a nice alternative. But unfortunately outside of the context of a <form><\/code>, a <button><\/code> is equally meaningless.<\/p>\n
<button>\r\n  Outside of a <form>, I'm just as useless.\r\n<\/button><\/code><\/pre>\n
But <button> feels better anyway<\/h3>\n
Even if a <button><\/code> doesn’t do anything outside of a form without the help of JavaScript, it still feels better for things you can click that do stuff other than change pages<\/em>. A bogus href link definitely doesn’t feel right.<\/p>\n
Alright. Let’s insert it with JavaScript then.<\/h3>\n
That’s probably the best solution. If JavaScript is required for the clickable-thing to do anything at all, it might as well not even be there at all unless JavaScript runs. We can do:<\/p>\n
\/\/ 1. Create the button\r\nvar button = document.createElement(\"button\");\r\nbutton.innerHTML = \"Do Something\";\r\n\r\n\/\/ 2. Append somewhere\r\nvar body = document.getElementsByTagName(\"body\")[0];\r\nbody.appendChild(button);\r\n\r\n\/\/ 3. Add event handler\r\nbutton.addEventListener (\"click\", function() {\r\n  alert(\"did something\");\r\n});<\/code><\/pre>\n
You could easily have “button adding” be a part of your JavaScript workflow.<\/p>\n
When links make more sense<\/h3>\n
If there is any kind of href you could put on that link that makes sense, by all means, use an anchor. Even if you override that behavior with JavaScript. That’s progressive enhancement at it’s finest. For instance:<\/p>\n