DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
63% Positive
Analyzed from 2619 words in the discussion.
Trending Topics
#button#buttons#form#link#links#proposal#cancel#web#action#should
Discussion (48 Comments)Read Original on HackerNews
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.
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-...
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.
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).
For example, that government sites enforce accessibility even without js.
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.
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.
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.
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...
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.
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...
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.
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.
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.
Yes, you have understood the proposal.
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
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.
And when did button get a formation property anyway?
I've been doing this forever and I'm still learning.
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
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/
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...
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...
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.
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.
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.
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.
Hell yea! Inching our way towards native HTMX.
I don’t see how this proposal is any different than what already exists.
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.
> 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.
https://news.ycombinator.com/item?id=48640974