Change form "action" attribute to "target" and add "action" attribute to buttons.

[alejsanc]

Change of the "action" parameter of the forms to "target" to indicate the URL where to execute the action. The "action" parameter is moved to the different buttons on the form and allows executing a different action with each of the buttons.

Example:

<form target="/article">
     <button action="delete">Delete</button>
     <button action="export">Export</button>
 </form>

[marcoscaceres]

I'm not sure this would be web compatible, given how forms work today (making this change might cause sites to break)... however, can't you do this maybe with a custom element(s)?

[alejsanc]

I'm not sure this would be web compatible, given how forms work today (making this change might cause sites to break)... however, can't you do this maybe with a custom element(s)?

The current mechanism of the form being sent to an address where an action is performed comes from the beginnings of the web when the form was sent to a CGI program.

Currently, the web has evolved to a REST model where an address is an object on which different actions are performed. Forms should evolve to this new way of doing things.

Change does not have to be traumatic. It can be done gradually. And the two methods can coexist.

[Gaubee]

1. Currently, this standard way of writing will send out the following link ?action=delete and ?action=export.

   <form action="#api" method="get">
     <button name="action" value="delete">Delete</button>
     <button name="action" value="export">Export</button>
   </form>

2. REST does not represent everything in the future. Even now, it can only represent a small part. If we want to make changes, we need more thoughtfully designed interfaces.
3. We should combine the design with the existing interface design, which can save developers’ learning costs and also better promote standardized interfaces. For example, URLPattern API:

   <form action-pattern="/books/:id(\\d)" method="get">
     <button name="id" value="1">Book-1</button>
     <button name="id" value="2">Book-2</button>
   </form>

[alejsanc]

When the button sends the form there is no problem because the value of the button is sent. But if you want to send the form in the background with XMLHttpRequest and FormData, the value of the pressed button is not included automatically.

Automatically including the value of this button would be nice. It must also be taken into account that this proposal is related to many others that I have made about forms and all of them should work together. The forms are missing many things. Now you have to add Javascript to them for anything.

Above all, it is related to adding the possibility of sending forms in the background with the "background" parameter.

[alejsanc]

3. We should combine the design with the existing interface design, which can save developers’ learning costs and also better promote standardized interfaces. For example, URLPattern API:
   ```
   <form action-pattern="/books/:id(\\d)" method="get">
     <button name="id" value="1">Book-1</button>
     <button name="id" value="2">Book-2</button>
   </form>
   ```

Can you explain to me what that code would do?

[alejsanc]

Let's take as an example the form for submitting comments on an issue on Github.

<form id="new_comment_form" aria-labelledby="previewable-comment-form-component-50505130-65f3-4ab2-b8e6-4f732f13f05b-title" autocomplete="off" class="js-new-comment-form js-needs-timeline-marker-header" data-turbo="false" action="/WICG/proposals/issue_comments" accept-charset="UTF-8" method="post">

Each issue has an address like the following:

/WICG/proposals/issues/126

The form is sent to this other address:

/WICG/proposals/issue_comments

And the issue number is sent as a parameter.

<input type="hidden" name="issue" value="126">`

There are two buttons. One to close with a comment and one to send a comment. One has the name "comment_and_close" and the value "1". The other has the class "btn-primary" and is unnamed.

<button name="comment_and_close" value="1" data-disable-with="" data-comment-text="Close with comment" formnovalidate="formnovalidate" type="submit" data-view-component="true" class="js-comment-and-button js-quick-submit-alternative btn BtnGroup-item flex-1">
    <span class="js-form-action-text" data-default-action-text="Close issue">Close with comment</span>
</button>`

<button data-disable-with="" data-disable-invalid="" type="submit" data-view-component="true" class="btn-primary btn">    Comment
</button>`

Five different things are mixed together when only one URL and two actions would be necessary.

<form target="/WICG/proposals/issues/126" background>
    <button action="comment_and_close">Close with comment</button>
    <button action="comment">Comment</button>
</form>

[alejsanc]

And if the form is in the URL of the object, the target parameter would not be necessary.

The "background" parameter would also not be necessary if the browser reacted differently depending on the server's response.

HTML document -> Change page
HTML fragment -> change that fragment
dialog element -> show dialog
message -> show message with accept button

And if the browser doesn't know what to do with the response, it passes it to a Javascript function.

<form callback="javascriptFunction()">
    <button action="comment_and_close">Close with comment</button>
    <button action="comment">Comment</button>
</form>