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.
> 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.
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 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'.
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.
> 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.
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.
> 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.
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 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.
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.
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.
18 comments
[ 0.27 ms ] story [ 13.5 ms ] threadHell yea! Inching our way towards native HTMX.
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.
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.
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.
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 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 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
And when did button get a formation property anyway?
I've been doing this forever and I'm still learning.
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.