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

31–40 of 55 posts

Re: The Difference Between a Button and a Link

#31

Post by alexpetros »

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.

What if I want the cancel button to be to the left of the submit button? This is how GitHub lays out those buttons, for instance. There's fundamentally no reason why a button's functionality should be dictated by its position on the page.

The proposal has an in-depth explanation of why this and other workarounds (like using the `form` attribute and a bunch of dangling forms) aren't sufficient.[0]

[0] https://triptychproject.org/proposals/button-actions#existin...

Re: The Difference Between a Button and a Link

#33

Post by bastawhiz »

alexpetros wrote: post #25
bastawhiz wrote: post #22

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

> 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. If I click "Edit" on a GitHub comment, it shows me two buttons, "Cancel" and "Update Comment." Patterns like this can be found all over the web on sites you certainly use. > There's functionally no reason to do this. It doesn't add anything for the user, it only takes t…

> If I click "Edit" on a GitHub comment, it shows me two buttons, "Cancel" and "Update Comment."

Cancel doesn't navigate. In fact, neither of them do.

> Buttons, for instance, can be activated with the spacebar.

If it's visually a link, you're not using the spacebar to activate it. If you've taken the twenty lines of css to make a button look like anything other than the default browser styles, you can add the two lines of progressive enhancement JavaScript to handle space.

> I included a link that showcases how this problem exists both in Django itself and for developers who build websites with Django.

The example the Django project calls out from the Django admin Change form is a really half-hearted example because the delete button isn't an action. It's literally a link to another page with a confirmation step. I have in my life right clicked that very link and opened it in a new tab. Moreover, there's no cosmetic benefit because they already style everything to look custom, so you're not even saving the CSS. Making that link into a button serves nobody, said as someone who maintains Django applications.

Re: The Difference Between a Button and a Link

#34

Post by bastawhiz »

rustystump wrote: post #27
bastawhiz wrote: post #22

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

Some of us do work on web apps not websites. Two different things. Websites should not be web apps. Web apps should take advantage of links when possible. The rigid mentality of everything in a browser must conform to some supercilious standard all to keep things “pure” I will never understand. We can have things like figma. It is ok for web apps to exist on the internet.

I'm not disagreeing with you. A button with an action serves neither a website developer nor a web app developer. Neither group pretends they're a native app. The web has fundamental idioms that people have gotten used to for thirty five years. If it takes you to another page and it's not submitting a form, you should be able to treat it the same everywhere. If I'm in figma, I'm smart enough to know what looks like something that'll navigate the browser. You don't need a new element to accomplish the same action.

Re: The Difference Between a Button and a Link

#35

Post by angrybards »

alexpetros wrote: post #29
angrybards wrote: post #24

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…

I'm not entirely sure what you mean by "in-between" element, but that's not what this proposal does. This proposal simply augments the button's existing ability to navigate the current context by removing the need to wrap it in a form. This is useful because sometimes buttons are already the right semantic element to use, but you can't use them to do this without JavaScript. Also, that link has a lot of wrong informa…

I wasn't under the impression it is a W3C site, for all I know it is AI generated and looks it to me. But, there are other blog posts I've coming across where this is discussed and that site did outline my point well enough which is changing norms like this can be hard for screen reader users who need to adapt to , and being controls performing very similar if not overlapping behaviour.

Currently these changes in norms happen because developers use links as buttons and buttons as links which can create confusion for the screen reader user / visual user who expects certain behavior based of the visual presentation of the control. Making button[action] standard in HTML codifies that behaviour though doesn't it?

I get that you are trying to effectively solve this problem, but it isn't so easy when this group of people are more reliant on norms. Maybe they would embrace a solution here if they were engaged with is all.

- https://adrianroselli.com/2016/01/links-buttons-submits-and-... - https://adrianroselli.com/2023/08/styling-links-and-buttons.... - https://karlgroves.com/links-are-not-buttons-neither-are-div...

Re: The Difference Between a Button and a Link

#36

Post by lelanthran »

bastawhiz wrote: post #22

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

Author addresses almost all your criticism in the material after the first few paragraphs.

For example, that government sites enforce accessibility even without js.

Re: The Difference Between a Button and a Link

#37

Post by alexpetros »

bastawhiz wrote: post #33
alexpetros wrote: post #25

Earlier quoted context omitted.

> 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. If I click "Edit" on a GitHub comment, it shows me two buttons, "Cancel" and "Update Comment." Patterns like this can be found all over the web on sites you certainly use. > There's functionally no reason to do this. It doesn't add anything for the user, it only takes t…

> If I click "Edit" on a GitHub comment, it shows me two buttons, "Cancel" and "Update Comment." Cancel doesn't navigate. In fact, neither of them do. > Buttons, for instance, can be activated with the spacebar. If it's visually a link, you're not using the spacebar to activate it. If you've taken the twenty lines of css to make a button look like anything other than the default browser styles, you can add the two li…

> Cancel doesn't navigate. In fact, neither of them do.

This is correct. The point of the proposal is that you should be able to implement this pattern with just navigations, and that implementing it differently doesn't change the user semantics.

> If you've taken the twenty lines of css to make a button look like anything other than the default browser styles, you can add the two lines of progressive enhancement JavaScript to handle space.

One important stakeholder for the proposal is governments and other websites that care about building accessible web experiences that work without JavaScript enabled. There are also many differences in the behaviors that can't be rectified with JavaScript (some examples are in the original article as well as the linked proposal).

Re: The Difference Between a Button and a Link

#38

Post by 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.

Re: The Difference Between a Button and a Link

#39

Post by alexpetros »

angrybards wrote: post #35
alexpetros wrote: post #29

Earlier quoted context omitted.

I'm not entirely sure what you mean by "in-between" element, but that's not what this proposal does. This proposal simply augments the button's existing ability to navigate the current context by removing the need to wrap it in a form. This is useful because sometimes buttons are already the right semantic element to use, but you can't use them to do this without JavaScript. Also, that link has a lot of wrong informa…

I wasn't under the impression it is a W3C site, for all I know it is AI generated and looks it to me. But, there are other blog posts I've coming across where this is discussed and that site did outline my point well enough which is changing norms like this can be hard for screen reader users who need to adapt to , and being controls performing very similar if not overlapping behaviour. Currently these changes in nor…

Totally, this is part of the problem I'm trying to solve. I wrote a little about these "call to action links" that you're describing in the proposal.[0] The tl;dr is that I think it would be easier to hold the line that "links should look like links" if we supported the legitimate use cases for navigating with buttons.

I would love more feedback from the accessibility engineering community so please look up my email or comment on the proposal if you think I've missed something.

[0] https://triptychproject.org/proposals/button-actions#what-ab...

Re: The Difference Between a Button and a Link

#40

Post by robinson7d »

alexpetros wrote: post #37
bastawhiz wrote: post #33

Earlier quoted context omitted.

> If I click "Edit" on a GitHub comment, it shows me two buttons, "Cancel" and "Update Comment." Cancel doesn't navigate. In fact, neither of them do. > Buttons, for instance, can be activated with the spacebar. If it's visually a link, you're not using the spacebar to activate it. If you've taken the twenty lines of css to make a button look like anything other than the default browser styles, you can add the two li…

> Cancel doesn't navigate. In fact, neither of them do. This is correct. The point of the proposal is that you should be able to implement this pattern with just navigations, and that implementing it differently doesn't change the user semantics. > If you've taken the twenty lines of css to make a button look like anything other than the default browser styles, you can add the two lines of progressive enhancement Jav…

While editing one GitHub comment I may be writing another. If you must, implement it as a link, but all else equal I’d prefer keeping the other state alive when canceling one comment-edit. Doing both is cool too, but people don’t typically want to implement a feature twice.
Post reply on HN