Regis Kuckaertz
2017-10-31 10:23:39 UTC
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 regards,
Regis
--
------------------------------
This e-mail and all attachments are confidential and may also be
privileged. If you are not the named recipient, please notify the sender
and delete the e-mail and all attachments immediately. Do not disclose the
contents to another person. You may not use the information for any
purpose, or store, or copy, it in any way. Guardian News & Media Limited
is not liable for any computer viruses or other material transmitted with
or as part of this e-mail. You should employ virus checking software.
Guardian News & Media Limited is a member of Guardian Media Group plc. Registered
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. Registered
in England Number 908396
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 regards,
Regis
--
------------------------------
This e-mail and all attachments are confidential and may also be
privileged. If you are not the named recipient, please notify the sender
and delete the e-mail and all attachments immediately. Do not disclose the
contents to another person. You may not use the information for any
purpose, or store, or copy, it in any way. Guardian News & Media Limited
is not liable for any computer viruses or other material transmitted with
or as part of this e-mail. You should employ virus checking software.
Guardian News & Media Limited is a member of Guardian Media Group plc. Registered
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. Registered
in England Number 908396