RadioNodeList and buttons

# Regis Kuckaertz (7 days ago)

Hello,

The other day I came across the following behaviour and would like to ask your opinion on the matter. It is not uncommon to find forms such as:

<form action="..."> <input type="hidden" name="itemId" value="123456789"> <button type="submit" name="action" value="star">Add to favourites</button> <button type="submit" name="action" value="copy">Duplicate</button> <button type="submit" name="action" value="delete">Delete</button> </form>

When a user presses one of these buttons, the UA picks the corresponding value and streamlines it in the form data, as expected. Yet if you try to catch the submit event in JavaScript, you won't be able to catch that value:

formElement.onsubmit = (evt) => { evt.preventDefault(); const button = evt.target.elements.namedItem('action'); const value = button.value console.log(value); // logs the empty string }

The reason for that is HTMLFormCollection.namedItem(name) returns a RadioNodeList. Here is the relevant part of the standard: "[if there is more than one node with id/name 'name',] create a new RadioNodeList object representing a live view of the HTMLFormControlsCollection object, further filtered so that the only nodes in the RadioNodeList object are those that have either an id attribute or a name attribute equal to name."

RadioNodeList is a NodeList where the value property, on getting, yields the value of the first <input type="radio"> element in tree order which

checkedness is true, or the empty string. In the above case, it is obvious that none of the buttons match that description.

There are two solutions that I know of: either give each button a unique name (but then the value becomes useless) or listen for click/keypress/touch events on these buttons; but somehow none of these solutions seem elegant to me.

Here is my question: if the UA handles this situation without a glitch, wouldn't you expect the corresponding DOM API to expose the same behaviour? It is true that, from the name of it, I wouldn't have expected it to work with anything but radio buttons, but then I wonder if this use case doesn't warrant either the creation of a similar ButtonNodeList, or a relaxation of the rule for getting the value.

Best

Contact us to advertise here
# Boris Zbarsky (7 days ago)

On 10/31/17 6:23 AM, Regis Kuckaertz wrote:

formElement.onsubmit = (evt) => { evt.preventDefault(); const button = evt.target.elements.namedItem('action'); const value = button.value

If this returned buttons, which button would you expect it to return in various situations and why?

Here is my question: if the UA handles this situation without a glitch, wouldn't you expect the corresponding DOM API to expose the same behaviour?

I just checked one UA (Firefox), and the way it handles this situation is that it stores the "submitter" (in the sense of the argument to html.spec.whatwg.org/#form-submission-algorithm) on the "submit" event itself. Exposing it as a property on that event would make a lot of sense to me.

# Regis Kuckaertz (6 days ago)

Thanks for your question. Phrased like that, it becomes clear to me that I did not think enough about how the value would be computed in the case of a set of buttons. There is no "checkedness" in buttons, not that I know of.

Indeed I find your idea more appealing and semantically clearer. When I wrote the example, I thought the name attribute on buttons was redundant with the type attribute.

# Boris Zbarsky (3 days ago)

On 10/31/17 10:56 AM, Regis Kuckaertz wrote:

Indeed I find your idea more appealing and semantically clearer.

OK, good. Since it's not just me, I filed whatwg/html#3195 on this.

# RĂ©gis Kuckaertz (2 days ago)
  • That's awesome, thank you.

Want more features?

Request early access to our private beta of readable email premium.