Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Difference Between a Button and a Link

unplannedobsolescence.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: The Difference Between a Button and a Link

#41

Post by _moof »

willthefirst wrote: post #38

> 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 /…

I do think cancel is a poor example because it's conceptually very near "go back" - but it doesn't actually mean that. It means "I've changed my mind".

Implementing cancel with a URL is an implementation detail. That's one way to do it, but it's far from the only way. Cancel could also be implemented by hiding a UI element, for example.

Re: The Difference Between a Button and a Link

#42

Post by chii »

_moof wrote: post #41
willthefirst wrote: post #38

> 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 /…

I do think cancel is a poor example because it's conceptually very near "go back" - but it doesn't actually mean that. It means "I've changed my mind". Implementing cancel with a URL is an implementation detail. That's one way to do it, but it's far from the only way. Cancel could also be implemented by hiding a UI element, for example.

> Cancel could also be implemented by hiding a UI element, for example.

Sometimes this can be confusing, because the hiding of the UI element doesn't prevent the submission of the form later. If the page is a giant form, with individual parts made to look separate (such as a large tax form), the cancel merely hiding the edited element (while retaining the data) means a later submission could inadvertently submit the data that was intended to be cancelled by the user.

Re: The Difference Between a Button and a Link

#43

Post by paulddraper »

TonyAlicea10 wrote: post #16
paulddraper wrote: post #8

Earlier quoted context omitted.

Well, the idea here is “things that look like buttons do page navigation.” And the proposal is that we should more closely align the presentation and function. You are correct that if you don’t care about alignment, there is nothing wrong with the status quo.

Presentation in what medium? A screen reader? You’re talking the user-agent stylesheet, which is a particular chosen presentation that I can change with my own CSS. I can make a button look like a link. You’re suggesting aligning to an inherently and deliberately changeable presentation. The idea is fine, but worry about what an HTML element “looks like” is not a good reason.

> You’re suggesting aligning to an inherently and deliberately changeable presentation.

Yes, you have understood the proposal.

Re: The Difference Between a Button and a Link

#44

Post by jasonkester »

alexpetros wrote: post #23
TonyAlicea10 wrote: post #4

> 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…

> This seems to conflate appearance with semantics. If an element causes a navigation, I make it a link. Neither of my examples work with links. Logout buttons must be buttons because they trigger unsafe requests, and "search" buttons are buttons because they submit the form as a query parameter. Both of these examples, are, however, navigations.[0] > Whether it looks like a button is irrelevant, that’s CSS. It's not…

“Logout buttons must be buttons because they trigger unsafe requests”

But this is just more of the pedantic developer nonsense that everyone is complaining about here.

I’ve built tons of sites in my time, and the logout “button” is always a link to “/?logout=1”. In 30 years, this has never caused a problem.

Re: The Difference Between a Button and a Link

#45

Post by bob1029 »

willthefirst wrote: post #38

> 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 /…

If cancellation involves abandoning server-side state, then calling an explicit action on the server could make sense. Buttons submit forms (aka mutate state on the server), links navigate to resources.

HN gets itself twisted into a knot over web dev "best practices" and tries way too hard to put things into certain ontological boxes. I would not overthink this. Empathize with the user and follow the vibes if you want a good UI/UX. Explore the nuance of the design space. Maybe buttons sometimes work for pure navigation too.

Re: The Difference Between a Button and a Link

#46

Post by oaxacaoaxaca »

The Triptych Project is a fantastic endeavor and we as a community should be fully supporting it. There's literally no downside; it only benefits. We can debate about whether Cancel should be a button or a link but please people don't throw shade at the idea of adding completeness to HTML.

Re: The Difference Between a Button and a Link

#47

Post by danaris »

marklar423 wrote: post #10
singpolyma3 wrote: post #2

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.

I had the same thought at first, but the example in the article convinced me. It's something I ran into when I did webdev. Form tags usually contain other elements - textboxes, checkboxes, etc. The url and method are specified on the form tag and not the button, so if you want a second submit button that goes to a different URL or use a different method, you need to duplicate all the other inputs in a separate form t…

Or

you can have the backend at the first URL detect which action should be taken based on which button was pressed, and act accordingly—even up to passing control off entirely to a different route/method.

Re: The Difference Between a Button and a Link

#48

Post by angrybards »

physicalecon wrote: post #7
TonyAlicea10 wrote: post #4

> 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…

Imagining you have a navigation to “/logout” that server side invalidates your token and redirects to home, would you implement that as a link? If so, what happens if someone tries to “open in a new tab” it?

Yea I think a form that posts is the right tool for the job here. It is clearly unsafe semantics.

Re: The Difference Between a Button and a Link

#49

Post by burntcaramel »

If you have a cancel button inside a form, you can point that button to another form dedicated to deleting with the form attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

I agree with some of this post but the argument feels muddled. "Clicking a logout button navigates the current page to a logged-out one" is wrong — it changes the state of the session, which is more than just a navigation. "Relative links can jump around the current page" — this _is_ a navigation.

I too weighed up the differences between a button and link and referenced the now sadly defunct WAI-ARIA Practices document which I found pretty clear: https://components.guide/accessibility-first/navigation

Post reply on HN