There are thousands of articles out there about buttons and links on the web; the differences and how to use them properly. Hey, I don’t mind. I wrote my own as well¹.
It’s such a common mistake on the web that it’s always worth repeating:
- Is the intention to send someone to another URL? It’s a link in the form of
<a href="">. - Is it to trigger some on-page interactivity? It’s a button in the form of
<button>. - Any devition from from those and you better smurfing know what you are doing.
Eric Eggert wrote a pretty good piece recently with a nice line about why it matters:
If you had a keyboard and your “e” key would only work 90% of the time, it would be infuriating. Reliability and trust in user interfaces is important to allow users to navigate content and application with ease. If you use the right elements, you support users.
Manuel Matuzović has a Button Cheat Sheet that is a lol-inducing ride about why literally everything other than a <button> isn’t as good as a button. Manuel links up Marcy Sutton’s epic The Links vs. Buttons Showdown (video), pitting the two against each other in a mock battle — “We’ll pit two HTML elements against each other in a crusade of better and worse, right and possible wrong. One element is triggered with the space bar, the other with the enter key. Who will win?” I don’t know whether to laugh or cry at how far we have to go to spread this information.
- I think our article A Complete Guide to Links and Buttons is a pretty good example of beginner-oriented content, which is my favorite style of content to write and publish! But because there is so much beginner-oriented content on the web, the bar is pretty high if you want to make and impact and get enough SEO for anyone to even ever find it. So, in this case, the idea was to go big and write nearly as much as there is to write about the technical foundation of links and buttons. If you’ve got a knack for this kind of writing, reach out for sure.
I think what doesn’t help is that for years the de facto way of validating a form was to use a button. By definition a form sends you to another URL (specified in the “action” attribute) so by your rules it should really behave like a link, which is not how a good old html form behaves by default.
Funny thing is if you look at the very form I’m typing in to leave a comment on this page, it will send me to
/wp-comments-post.php, and even though the “POST COMMENT” thing is not technically a link, it kind of behaves like one in that the cursor changes to the pointing finger on hover to indicate I’ll change page… So that’s OK I guess.But now if I look at the “Write” and “Preview” things at the bottom of the textarea, well they should really be buttons because they won’t redirect me to a different page… And yet they’re good old
<a>tags with the pointing finger cursor.So yeah, my guess is we’ll still be discussing this years from now.
Something I was wondering because I often do it: what about opening modals/overlays (that have static content) with a
<a href="#thiscontent">? Semantically, it is just a link to an other part of the content, even if it ends up looking like a button and “on-page interactivity” but that’s just appearances.If Javascript is disabled, the modal can be displayed with CSS :target. If Javascript and CSS are not active, the page will nicely scroll to the content.
To me it makes a lot of sense but maybe there are aspects of it I’m not thinking of.