Links are not buttons (2013)

The problem is that links provide a very reliable way to perform a controlled HTTP request to get a dynamic response from the backend.... without using JavaScript. I love JavaScript, but if device reusability is a serious concern then JavaScript is the elephant in the room, not this topic. Is it available? What version is supported? What quirks does the engine have? To be fair... it was posted in 2013 :D.<p>The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward&#x2F;back, refresh) are laden with &quot;you&#x27;re about to resend data!&quot; warnings that completely break the flow.<p>To me, it makes perfect sense why this trend evolved. Most people agree with the underlying premise about user expectation on button vs link. Dressing links up as button is a direct response to that. I understand the technical arguments, but users care what it looks like and how it behaves, not how you implemented it.<p>Edits:<p>- Yes, you can use &lt;form method=&quot;get&quot;...&gt; without scary browser warnings. It just gets a but ugly if you have lots of buttons, as each needs its own form wrapper.<p>- 303 redirects to POST request are a handy pattern to be aware of no matter what :)

Everything is a button now that javascript applications have replaced HTML documents. And there are no such things as anchors or links anymore. They are not URLs but instead triggers for more javascript execution. We&#x27;re, unfortunately, well past this minor problem and onto much more serious ones that eclipse it.

And never use href=&quot;#&quot; or href=&quot;javascript:void(0)&quot;: middle-clicking on it will lead to unexpected results.<p><i>I&#x27;m looking at you, Hacker News</i>

I think the converse—buttons are not links—doesn&#x27;t get enough attention. The litmus test is that if clicking it is supposed to navigate, you should also be able to shift+click or middle-click to open it in a new tab, or drag it up to your toolbar to make a bookmark.

One pet peeve of mine with the button-ish links is that sometimes they only work if I click <i>on the text itself</i>.

Buttons do something.<p>Links go somewhere.<p>Don&#x27;t cross the streams.

I think 90% of the misuse arises from devs not realizing that they can use a &lt;button&gt; or &lt;a&gt; (or whatever else is correct in that context) and still style it however they want.

Big pet peeve: Web apps where some buttons look like buttons and some buttons look like links. Everything that initiates an action of some sort should look the same, damnit.

Historically, styling buttons wasn&#x27;t supported. The result of styling an input element of type submit and a button element were different too. It eroded adherence to proper semantics. I think people are still used to the workaround which is use an anchor element.

His main points are about accessibility but there&#x27;s a lot of overlap between accessibility and SEO. Google needs semantic tags to understand your site. It will treat any &lt;a&gt; as navigation and won&#x27;t do the same for &lt;button&gt; or any other approach. The basic premise that &lt;button&gt; is for CTAs and &lt;a&gt; is for navigation is the golden rule. You can style either anyway that you want.

Honestly, if you spend energy worrying about this issue, it&#x27;s like using a bucket to bail water out of a sinking cruise ship.

I agree with the author...partly.<p>Sure, &lt;divs&gt; and &lt;spans&gt; are not buttons and should not ever be used as those. Knowing and adhering to standards, especially when they are there for accessibility, is an excellent thing.<p>But in some cases, making links links instead of buttons (and similar scenarios) just means exposing internal works to the user. Say I have a SaaS with the classic &quot;GET STARTED NOW&quot; button on the landing page. Now I change my tech stack from something classic like Rails or Lavarel, where &quot;get started&quot; probably means a link to the signup page to some fancy JavaScript which triggers the action of overlaying a signup form. Would you really agree that the HTML for my &quot;GET STARTED NOW&quot; button should change depending on what kind of method my app uses?