Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.
    by oaxacaoaxaca
  • I agree: buttons do something, links go somewhere
    by m463
  • 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.
    by dwheeler
  • > 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.

    by willthefirst
  • 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.

    by bob1029
  • 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.

    by _moof
  • 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'.
    by OptionOfT
  • 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

    by angrybards
  • 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/

    by alexpetros
  • 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.

    by jorams
  • > 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.

    by wxw
  • 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.

    by christophilus
  • 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

    by burntcaramel
  • 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.
    by singpolyma3
  • > 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.

    by TonyAlicea10
  • 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?
    by physicalecon
  • 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.

    by paulddraper
  • > 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...

    by alexpetros
  • 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.
    by singpolyma3
  • And don't forget about the `form` attribute to associate a button with any arbitrary form element by ID.
    by crooked-v
  • 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...

    by alexpetros
  • 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.

    by marklar423
  • > 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.

    by bastawhiz
  • 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.

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

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

    by lelanthran
  • > 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-...

    by alexpetros