Every reply an <action-button> or an <action-select> can get, and every arrangement of them. Nothing here touches anything: the handler looks at which value came in and answers with the matching reply.
A row of buttons
The row shares one box, under all of it, holding whatever the last press said. The button that was pressed is the one wearing the mark.
A button on its own
A row of one: the box sits under the single button.
Buttons with nothing wrapping them
Written straight into the form rather than into a <div> of their own, so the form is the row and the box lands after the last of them.
A select
Picking an option is what sends it -- there's nothing else to press -- and the mark sits beside the select rather than inside it. A reply that isn't a success puts the option that was showing back, so what's on screen is only ever a value the server took. The disabled one can't be opened.
A select that opens on a stored value
Both of these say selected= rather than marking an option selected: the first is an <action-select> and posts from wherever it starts, the second is a <good-select>, which is the same attribute on a select that does nothing else. A value no option carries would leave the select blank and say so in the console.
A select added after the page
The button builds a <good-select selected=one> and appends it, so it was never on the page to be read at load. It still comes up on "One error": being an element of ours, it is read when it goes in, whenever that is. Its options have to be in it before that, which is why they are appended first.
A control the page has a condition about
A boolean attribute is on because it is written, so a page holding a condition has had to decide whether to write disabled at all. enabled= takes the condition as its value instead -- the two words a boolean writes -- and says it the way round the page has it. Saying nothing is live; anything but true or false is dead and says so in the console.
A select and a button in one row
One box between them, as for any row: the last one used is what it's about, and the other one loses its mark. The button names nothing itself, so what it sends is whatever the select is showing.
A form the browser won't let go
The field is required, so pressing either button gets the browser's own complaint and sends nothing.
The same, with a select: it goes back to the option it was showing. Nothing was stored, so nothing on screen should say it was.
Several of a list
A <multi-select>. Type to narrow the list, enter or a press takes the row the arrows are on, and a press on a chip takes that pick back off. A backspace in an empty box removes the whole last pick, which is the thing a list of words in a textarea can't do. Nothing goes in that isn't on the list.
Both of these send one field with one value a line, because a form can't name the same field twice. "Say what came in" prints what arrived, so what a control sends can be looked at rather than assumed.
Picking into a box the page already has
into= names the box a pick is a line of, instead of the control holding a set of picks: no chips, nothing sent, nothing to open on, and what was picked is now text to be edited as text. The value is the whole line, so a box wanting more than the words gets it. This is modcp's search, where a usergroup is one line kind among IPs and usernames.
A multi-select added after the page
The same as the select above: its options have to be in it before it goes into the document, since that is when they are read.
Cropping pictures
An <image-edit> wraps the control the pictures come from and a hidden field for what was measured. Drag the rectangle or a corner of it, set the size to save at, and the field fills in below; Reset hands the picture back untouched. Nothing here posts -- the server-side cutting is uploads/edit.ts, and this is only the measuring.
What each field holds
A server that isn't there
Points at a port nothing is listening on, which is the one failure that never reaches a handler.