3 ms·

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 be

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.

crooked-v 2mo ago
And don't forget about the `form` attribute to associate a button with any arbitrary form element by ID.
marklar423 2mo ago
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.
- minitech 2mo ago
  The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#formaction https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - wky 2mo ago
    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.
  - marklar423 2mo ago
    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.
    - zerocrates 2mo ago
      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.
      - singpolyma3 2mo ago
        But there is no semantically valid reason for the button to be in the form if it doesn't submit the form. So move it outside.
- danaris 2mo ago
  Or 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.
alexpetros 2mo ago
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#existing-workarounds https://triptychproject.org/proposals/button-actions#existin...
- singpolyma3 2mo ago
  What parent the button has shouldn't have any meaningful limit on how you can style it with modern CSS.

crooked-v 2mo ago

And don't forget about the `form` attribute to associate a button with any arbitrary form element by ID.

marklar423 2mo ago

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.

minitech 2mo ago
The `formaction` and `formmethod` attributes already exist. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#formaction https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- wky 2mo ago
  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.
- marklar423 2mo ago
  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.
  - zerocrates 2mo ago
    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.
    - singpolyma3 2mo ago
      But there is no semantically valid reason for the button to be in the form if it doesn't submit the form. So move it outside.
danaris 2mo ago
Or 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.

alexpetros 2mo ago

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#existing-workarounds https://triptychproject.org/proposals/button-actions#existin...

singpolyma3 2mo ago
What parent the button has shouldn't have any meaningful limit on how you can style it with modern CSS.