5 ms·

The Difference Between a Button and a Link

67 points by alexpetros 2mo ago

singpolyma3 2mo ago
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.
- crooked-v 2mo ago
  And don't forget about the `form` attribute to associate a button with any arbitrary form element by ID.
- marklar423 2mo ago
  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 tag with your button. All of this can be done with scripting, but the point of this proposal is to make that unnecessary.
  - minitech 2mo ago
    The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#formaction https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
    - wky 2mo ago
      Additionally, the proposal of button actions is for the opposite purpose, when you want to avoid sending the form data when the button is pressed.
    - marklar423 2mo ago
      I stand corrected, thanks for pointing it out. I suppose then I'm back to not seeing the utility of the proposal over form tags.
      - zerocrates 2mo ago
        I guess the distinction would be that in the formaction/formmethod case you'll also submit all the other form data, while the button action will just be an empty body. An extra blank form on the page and the form attribute on the button can work around that, and at that point the argument would basically be: this is super clunky.
        singpolyma3 2mo ago
        But there is no semantically valid reason for the button to be in the form if it doesn't submit the form. So move it outside.
  - danaris 2mo ago
    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.
- alexpetros 2mo ago
  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#existing-workarounds https://triptychproject.org/proposals/button-actions#existin...
  - singpolyma3 2mo ago
    What parent the button has shouldn't have any meaningful limit on how you can style it with modern CSS.
wxw 2mo ago
> 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.
- christophilus 2mo ago
  Buttons already have actions and methods and many other useful things: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#formaction https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... I don’t see how this proposal is any different than what already exists.
  - Kuyawa 2mo ago
    TIL, thank you
  - alexpetros 2mo ago
    You linked to `formaction`, which allows buttons to control the action of their nested form. This proposal allows buttons to make actions independent of forms, and the blog has an example of how independent button actions compose nicely with the existing `formaction` and `formmethod` controls.
TonyAlicea10 2mo ago
> 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.
- physicalecon 2mo ago
  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?
  - angrybards 2mo ago
    Yea I think a form that posts is the right tool for the job here. It is clearly unsafe semantics.
- paulddraper 2mo ago
  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.
  - TonyAlicea10 2mo ago
    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.
    - 2mo ago
greatsage_sh 2mo ago
[flagged]
zhonglin 2mo ago
[flagged]
dwheeler 2mo ago
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.
theChris-in 2mo ago
[flagged]
OptionOfT 2mo ago
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 2mo ago
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.
- angrybards 2mo ago
  REST doesn't care about the content of your URI path / query as long as it is unique to the resource and POST's semantics are so flexible you can perform any action with it: > The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others): https://httpwg.org/specs/rfc9110.html#rfc.section.9.3.3 https://httpwg.org/specs/rfc9110.html#rfc.section.9.3.3 There are some niceties to using PUT and DELETE, but different reasons.
- wodenokoto 2mo ago
  Didn’t they just add “query”? https://news.ycombinator.com/item?id=48640974 https://news.ycombinator.com/item?id=48640974
bastawhiz 2mo ago
> 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.
- alexpetros 2mo ago
  > 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 things away in the name of making it feel "more native". There are many functional differences between buttons and links and it's not true that links are strictly more capable. Buttons, for instance, can be activated with the spacebar. > I've been building websites for 25 years and I've literally never had this problem. I included a link that showcases how this problem exists both in Django itself and for developers who build websites with Django.[0] This is representative of a durable, hypertext-driven, webapp design that the proposals are intended to support. [0] https://www.djangoproject.com/weblog/2026/jul/15/supporting-the-triptych-project/ https://www.djangoproject.com/weblog/2026/jul/15/supporting-...
  - bastawhiz 2mo ago
angrybards 2mo ago
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 https://www.thewcag.com/examples/buttons-links
- alexpetros 2mo ago
  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 information and is not an official W3C site. It even has a LinkedIn page.[0] [0]https://www.linkedin.com/company/thewcagcom/ https://www.linkedin.com/company/thewcagcom/
  - angrybards 2mo ago
    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 <a>, <button> and <button action> 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-divs-oh-hell.html https://adrianroselli.com/2016/01/links-buttons-submits-and-... - https://adrianroselli.com/2023/08/styling-links-and-buttons.html https://adrianroselli.com/2023/08/styling-links-and-buttons.... - https://karlgroves.com/links-are-not-buttons-neither-are-divs-and-spans/ https://karlgroves.com/links-are-not-buttons-neither-are-div...
m463 2mo ago
I agree: buttons do something, links go somewhere
willthefirst 2mo ago
> 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.
- _moof 2mo ago
  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.
  - chii 2mo ago
    > 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.
- bob1029 2mo ago
  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.
oaxacaoaxaca 2mo ago
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.
burntcaramel 2mo ago
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/Attributes/form 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 https://components.guide/accessibility-first/navigation
- singpolyma3 2mo ago
  Even better, don't put it inside that form. If it isn't submit (or clear) the form then the button has no semantic business being parented by the form.
oliwarner 2mo ago
The opening code sample should be formaction, not action, right? (Edit, I see, it's a proposal) And when did button get a formation property anyway? I've been doing this forever and I'm still learning.
jorams 2mo ago
While I understand and perhaps even agree with the semantic argument, the reality of the web is that this will be abused. A sane implementation for a browser would be for an action button with method="get" to get basically all of the affordances a normal link has, e.g. middle click, context menu actions. Sites already exist that hide navigation behind non-links. Now they need to write JS to make that happen, which is at least a bit of a deterrent. The proposal actually fully treats this as desirable: > When web authors style links to look like buttons, they inherit the responsibility to make links behave like buttons in all possible contexts. No, they don't. A web author that works to disable core functionality for links should be fired into the sun, not given easier tools to do so. If your action is really just a navigation, then the user should have the ability to treat it as such.

67 points by alexpetros 2mo ago

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.

crooked-v 2mo ago
And don't forget about the `form` attribute to associate a button with any arbitrary form element by ID.
marklar423 2mo ago
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 tag with your button. All of this can be done with scripting, but the point of this proposal is to make that unnecessary.
- minitech 2mo ago
  The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#formaction https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - wky 2mo ago
    Additionally, the proposal of button actions is for the opposite purpose, when you want to avoid sending the form data when the button is pressed.
  - marklar423 2mo ago
    I stand corrected, thanks for pointing it out. I suppose then I'm back to not seeing the utility of the proposal over form tags.
    - zerocrates 2mo ago
      I guess the distinction would be that in the formaction/formmethod case you'll also submit all the other form data, while the button action will just be an empty body. An extra blank form on the page and the form attribute on the button can work around that, and at that point the argument would basically be: this is super clunky.
      - singpolyma3 2mo ago
        But there is no semantically valid reason for the button to be in the form if it doesn't submit the form. So move it outside.
- danaris 2mo ago
  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.
alexpetros 2mo ago
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#existing-workarounds https://triptychproject.org/proposals/button-actions#existin...
- singpolyma3 2mo ago
  What parent the button has shouldn't have any meaningful limit on how you can style it with modern CSS.

wxw 2mo ago

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

christophilus 2mo ago
Buttons already have actions and methods and many other useful things: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#formaction https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... I don’t see how this proposal is any different than what already exists.
- Kuyawa 2mo ago
  TIL, thank you
- alexpetros 2mo ago
  You linked to `formaction`, which allows buttons to control the action of their nested form. This proposal allows buttons to make actions independent of forms, and the blog has an example of how independent button actions compose nicely with the existing `formaction` and `formmethod` controls.

TonyAlicea10 2mo ago

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

physicalecon 2mo ago
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?
- angrybards 2mo ago
  Yea I think a form that posts is the right tool for the job here. It is clearly unsafe semantics.
paulddraper 2mo ago
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.
- TonyAlicea10 2mo ago
  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.
  - 2mo ago

greatsage_sh 2mo ago

[flagged]

zhonglin 2mo ago

[flagged]

dwheeler 2mo ago

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.

theChris-in 2mo ago

[flagged]

OptionOfT 2mo ago

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 2mo ago

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.

angrybards 2mo ago
REST doesn't care about the content of your URI path / query as long as it is unique to the resource and POST's semantics are so flexible you can perform any action with it: > The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others): https://httpwg.org/specs/rfc9110.html#rfc.section.9.3.3 https://httpwg.org/specs/rfc9110.html#rfc.section.9.3.3 There are some niceties to using PUT and DELETE, but different reasons.
wodenokoto 2mo ago
Didn’t they just add “query”? https://news.ycombinator.com/item?id=48640974 https://news.ycombinator.com/item?id=48640974

bastawhiz 2mo ago

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

alexpetros 2mo ago
> 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 things away in the name of making it feel "more native". There are many functional differences between buttons and links and it's not true that links are strictly more capable. Buttons, for instance, can be activated with the spacebar. > I've been building websites for 25 years and I've literally never had this problem. I included a link that showcases how this problem exists both in Django itself and for developers who build websites with Django.[0] This is representative of a durable, hypertext-driven, webapp design that the proposals are intended to support. [0] https://www.djangoproject.com/weblog/2026/jul/15/supporting-the-triptych-project/ https://www.djangoproject.com/weblog/2026/jul/15/supporting-...
- bastawhiz 2mo ago

angrybards 2mo ago

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 https://www.thewcag.com/examples/buttons-links

alexpetros 2mo ago
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 information and is not an official W3C site. It even has a LinkedIn page.[0] [0]https://www.linkedin.com/company/thewcagcom/ https://www.linkedin.com/company/thewcagcom/
- angrybards 2mo ago
  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 <a>, <button> and <button action> 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-divs-oh-hell.html https://adrianroselli.com/2016/01/links-buttons-submits-and-... - https://adrianroselli.com/2023/08/styling-links-and-buttons.html https://adrianroselli.com/2023/08/styling-links-and-buttons.... - https://karlgroves.com/links-are-not-buttons-neither-are-divs-and-spans/ https://karlgroves.com/links-are-not-buttons-neither-are-div...

m463 2mo ago

I agree: buttons do something, links go somewhere

willthefirst 2mo ago

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

_moof 2mo ago
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.
- chii 2mo ago
  > 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.
bob1029 2mo ago
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.

oaxacaoaxaca 2mo ago

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.

burntcaramel 2mo ago

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/Attributes/form 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 https://components.guide/accessibility-first/navigation

singpolyma3 2mo ago
Even better, don't put it inside that form. If it isn't submit (or clear) the form then the button has no semantic business being parented by the form.

oliwarner 2mo ago

The opening code sample should be formaction, not action, right? (Edit, I see, it's a proposal) And when did button get a formation property anyway? I've been doing this forever and I'm still learning.

jorams 2mo ago

While I understand and perhaps even agree with the semantic argument, the reality of the web is that this will be abused. A sane implementation for a browser would be for an action button with method="get" to get basically all of the affordances a normal link has, e.g. middle click, context menu actions. Sites already exist that hide navigation behind non-links. Now they need to write JS to make that happen, which is at least a bit of a deterrent. The proposal actually fully treats this as desirable: > When web authors style links to look like buttons, they inherit the responsibility to make links behave like buttons in all possible contexts. No, they don't. A web author that works to disable core functionality for links should be fired into the sun, not given easier tools to do so. If your action is really just a navigation, then the user should have the ability to treat it as such.