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.
The Difference Between a Button and a Link
11–20 of 55 posts
Re: The Difference Between a Button and a Link
#12You 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 t…
The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Re: The Difference Between a Button and a Link
#13[flagged]
Re: The Difference Between a Button and a Link
#14I 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'.
Re: The Difference Between a Button and a Link
#15Earlier quoted context omitted.
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 t…
The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Additionally, the proposal of button actions is for the opposite purpose, when you want to avoid sending the form data when the button is pressed.
Re: The Difference Between a Button and a Link
#16> 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…
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.
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.
Re: The Difference Between a Button and a Link
#17Earlier quoted context omitted.
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 t…
The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I stand corrected, thanks for pointing it out. I suppose then I'm back to not seeing the utility of the proposal over form tags.
Re: The Difference Between a Button and a Link
#18I 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.
Re: The Difference Between a Button and a Link
#19> 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.
Re: The Difference Between a Button and a Link
#20Earlier quoted context omitted.
The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I stand corrected, thanks for pointing it out. I suppose then I'm back to not seeing the utility of the proposal over form tags.
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.
An extra blank form on the page and the form attribute on the button can work around that, and at that point the argument would basically be: this is super clunky.