Not css but html5. It allows you to have multiple submit buttons, each linked to a different action through the formaction attribute. So I have an "add item" bu

Not css but html5. It allows you to have multiple submit buttons, each linked to a different action through the formaction attribute. So I have an "add item" button that submits all fields (of the whole document) to a "/foo/form/add_item" route and simply adds a row of empty inputs. All other fields are filled with the same values they were submitted with. I also have a submit button per row where each has an action with a route that includes the index of the item to be deleted. Likewise, all fields are submitted, the indicated row is omitted, and all other fields are rendered with the values they were submitted with. I got the backend prepared to facilitate this. I just call a function with another function that manipulates a datatype representing the form. It parses the submitted data into that, passes it through my function argument, renders it, and responds with it. In the example I gave, the HTML table holds the inputs for the row data, but initially I thought the items would need more fields than would be pleasant to work with in the table. What I was doing then was displaying a subset of the data in the table, hold the raw data of all items in hidden fields, and have a subform below the table for new items and item edition. This was somewhat more complicated, specially because of the way the backend framework I was using thought of forms. I had one HTML form that I wanted to treat like multiple, validating one or the other depending on what submit button was used. Getting that to work in Yesod was a little troublesome but I imagine it would have been easier (though less safe) in e.g. Rails. Anyway, I think continuing that way would probably have also been doable, had I not switched to having the inputs in the HTML table for simplicity.