> 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.
> 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.
> 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.
> 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).
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.
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.
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 tag with your button.
All of this can be done with scripting, but the point of this proposal is to make that unnecessary.
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.
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.
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]
> 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.
> 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 irrelevant, because even if you style a link like a button (or vice versa), it will still behave like the thing it actually is. That's why it's important to have native HTML behavior that lets people use the right semantic element.
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?
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.
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.
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.
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.
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.
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]
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.
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.
> 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.
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.
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.
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'.
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.
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.
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.
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):
> 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.
> 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-...
> 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.
> 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).
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.
Author addresses almost all your criticism in the material after the first few paragraphs.
For example, that government sites enforce accessibility even without js.
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.
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 tag with your button.
All of this can be done with scripting, but the point of this proposal is to make that unnecessary.
The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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.
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.
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.
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.
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...
And don't forget about the `form` attribute to associate a button with any arbitrary form element by ID.
> 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.
> 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 irrelevant, because even if you style a link like a button (or vice versa), it will still behave like the thing it actually is. That's why it's important to have native HTML behavior that lets people use the right semantic element.
[0] https://html.spec.whatwg.org/multipage/browsing-the-web.html...
“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.
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.
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.
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
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.
> 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.
Buttons already have actions and methods and many other useful things: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I don’t see how this proposal is any different than what already exists.
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.
TIL, thank you
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
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/
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-... - https://adrianroselli.com/2023/08/styling-links-and-buttons.... - https://karlgroves.com/links-are-not-buttons-neither-are-div...
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...
> 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.
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.
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.
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'.
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.
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.
I agree: buttons do something, links go somewhere
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.
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.
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
There are some niceties to using PUT and DELETE, but different reasons.
Didn’t they just add “query”?
https://news.ycombinator.com/item?id=48640974
Is this too tech for hacker news? LOL
[flagged]
[flagged]