The Difference Between a Button and a Link

singpolyma3

You can have button actions today by wrapping the button in a form tag. The article even shows this. The implication seems to be somehow that this is no good because what if you're already in a form tag? The answer is to move the two actions which aren't actually related to the form outside of the form tag and give them their own unique form parents.

wxw

> The proposal itself is very straightforward: we want to add the action and method attributes to the button. Hell yea! Inching our way towards native HTMX.

TonyAlicea10

> Buttons regularly perform navigations. Clicking a logout button navigates the current page to a logged-out one; clicking a “search” button navigates the current page to the query results. This seems to conflate appearance with semantics. If an element causes a navigation, I make it a link. Whether it looks like a button is irrelevant, that’s CSS. I always choose one or the other by intended behavior first, and that always works out great. That said, I like the idea.

zhonglin

Is this too tech for hacker news? LOL

dwheeler

I love this, and more generally the Triptych Project. We shouldn't need to use JavaScript to work around important limitations in HTML that are widely needed.

OptionOfT

I don't like how links are abused next to buttons in dark patterns. E.g. in Windows, when its pushing OneDrive to you, it'll ask you a question and it'll be a button 'Yes, pay $x', and then a link that's like 'maybe later'.

acabal

I see this is part of the Triptych project, an attempt to, among other things, bring more verbs into HTML forms. As I've said before one of my long-time dreams is to have HTML forms support methods other than GET and POST. Clicking on forms is how humans interact with HTTP, and for some strange reason the web has evolved to omit many very important words us humans must use to communicate. While a machine is allowed to say `DELETE /widgets/123`, a human is forced to say `POST /widgets/123/delete` or `POST /widgets/123?_method=DELETE`. This is not only semantically incorrect, but also results in idempotency and caching issues, and, perhaps worst of all, forces developers to maintain two separate APIs: nice, well-formed REST endpoints for machines, and separate kludgy endpoints for humans, who were granted a stunted language.

bastawhiz

> Copying, sharing, bookmarking—these are all features for re-contextualizing the action of a link. Buttons serve a complimentary purpose because they don’t allow for any of that. This sells me on the opposite of what the author is saying. If, because some jackass decided that to open a page in a different window I need to click the button, copy the URL, then go back and open a new tab, then paste, that's a terrible experience. This proposal presupposes that the developer is smarter than the user (they're frequently not!). There's functionally no reason to do this. It doesn't add anything for the user, it only takes things away in the name of making it feel "more native". > Should “Cancel” be a link? No! Its job is to close the edit view. I've been building websites for 25 years and I've literally never had this problem. And that's partially because "Cancel" is pretending you're in a desktop app with desktop idioms. No real, actual person designs websites like this. And the number of people who are doing zero styling but who also care about the distinction between a link and a button is vanishingly small. It's simple: just stop trying to be clever. Design a website like you're writing hypertext.

angrybards

Screen readers use the clear semantic difference between a button and a link to make sure the user knows what to expect and users are used to the different keyboard shortcuts. I saw in your specification an example where a website made effort to work around this clear separation and from what I could tell there may have been user testing, but in other places I see that usability is best for screen reader users where the semantics are clear. This proposal would standardize an in between element, adding a third form they have to understand with different behaviors. I guess just make sure you get some experienced accessibility feedback in your submission. https://www.thewcag.com/examples/buttons-links

m463

I agree: buttons do something, links go somewhere

willthefirst

> Should “Cancel” be a link? No! Its job is to close the edit view. Not only does making this a link incorrectly communicate its purpose—visually and otherwise—but it saddles the form “control” with lots of features, like bookmarking and middle-clicking, that have incorrect behavior. I don’t get this. Cancel takes you back to the read-only view of the form. So if /resource/edit is the form, cancel just takes you to /resource. So is this “performing an action” or “navigating somewhere”? Hard to tell. I’m saying that if cancelling a form edit just means ditching the local state to go back to the normal view, that should be a navigation. Someone straighten this out for me.