21–30 of 55 posts
> 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.
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.
> 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…
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...
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.
> 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…
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 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.
> 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…
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 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 t…
> 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.
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…
Also, that link has a lot of wrong information and is not an official W3C site. It even has a LinkedIn page.[0]
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 t…