Comment by mr-wendel | Hacker News Reader

Comment by mr-wendel | Hacker News Reader

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.

The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward/back, refresh) are laden with "you're about to resend data!" warnings that completely break the flow.

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.

Edits:

- Yes, you can use <form method="get"...> without scary browser warnings. It just gets a but ugly if you have lots of buttons, as each needs its own form wrapper.

- 303 redirects to POST request are a handy pattern to be aware of no matter what :)

> The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward/back, refresh) are laden with "you're about to resend data!" warnings that completely break the flow.

You can make a form with method="GET" that doesn’t do this, works the same way a link would, and can send form data.

> The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward/back, refresh) are laden with "you're about to resend data!" warnings that completely break the flow.

If anyone is looking for a solution to this, you can respond to a POST with a 303 (See Other) redirect. There's even a Wikipedia page for this pattern: https://en.wikipedia.org/wiki/Post/Redirect/Get

You’re missing the point of the article entirely.

The author argues to NOT use fake anchor tags like <a href="#"> and then add functionality to it via JavaScript. Instead you should use <button type="button">.

Either way, JavaScript is required.

What you’re suggesting means your link is actually a link to another page, which works without JavaScript and that’s not the point of the article.

    <form action="whatever" method="get">

or has that not been around for long? I haven't found anything stating when it first arrived.

Since HTML 2.0 at least. Before that I think the method was specified as part of the action attribute.

Given that the default method is get, and you have to set method=post for otherwise, I'd suspect it's been around longer than method=post.

Can't edit now, so also adding this: you can't nest forms which may unnecessarily complicate some layouts

Noting that you can use form="my-id" to have the fields outside the form tag, though that might be the complications you mentioned.

Never ceases to amaze me that I've been using HTML for more than 25 years, and every now and then I still learn a new nugget this and wonder how I could have not known!

It would be really nice to have a button that doesn't navigate away and doesn't require JS.

And that doesn't even get into CSS styling.

You know a link starts with the exact same height and font that surrounds it, and then you can style it to predictably know exactly what you'll get.

A button shows up in a new font -- a font of unknown size at that, because it utterly ignores the font size of its container -- with extra height that introduces line-spacing issues -- and all of this by totally unpredictable amounts because it varies radically across both browser and platform. And if you want to undo all that styling, have fun delving into the quirks of each browser of how to do so.

If you're building something simple where appearance really doesn't matter, then sure throw in a button. But if you actually want to have predictable results, then the only straightforward way is with a link you style.

  .button {
    all: unset;
    /* continue styling */
  }

Huh, TIL. Looking it up on MDN, looks like that was implemented in WebKit in 2016. Even HTML5 didn't have that, while <button> has been around since the late 1990's.

Well, very happy to know that's no longer the case then, thanks! One more thing in CSS that's finally been addressed.

I really dislike this because it now makes the buttons not look like my platform’s buttons. I know this ship has sailed, but there are resets out there that allow you to fix most of the styling issues without making the buttons look like not-buttons.

It was possible to entirely reset the appearance of the button element before 2016.

Buttons shouldn't be in the middle of a sentence or paragraph, so not sure how this applies.

Take a look at the HN voting buttons. Or, better yet, the expand/collapse button for each comment thread. They are implemented as links, not buttons. Presumably, this makes it easier to align with the text that they are within.

HN isn’t a great example here, it’s still one of the last sites still using tables for layout.

According to whom?

Reply on news.ycombinator.com