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.
> 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.
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 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.
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 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.
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.
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.
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.
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.
Hell yea! Inching our way towards native HTMX.
I don’t see how this proposal is any different than what already exists.