I have a multiple select form that looks like this:
<select multiple="multiple" id="id_form-0-project" name="form-0-project">
<option value="0">and another test</option>
<option value="1">another test</option>
<option value="2" selected="selected">one more test</option>
<option value="3">test project</option>
</select>
As one can see, there is one selected value. This is always the first option that I select. However, when I select multiple options with shift click or command click, the newly selected items are not adjusted so as to contain the selected="selected" attribute, even though visually, it appears to the user that said selections are highlighted.
In this respect it is acting like a single selector, but I figured that adding the "multiple="multiple" attribute would allow for assigning the selected attribute to multiple options.
Is this a common problem? Could it have something to do with page reloading? What is the expected behavior?
For windows: Hold down the control (ctrl) button to select multiple options. For Mac: Hold down the command button to select multiple options.
Dropdown lists are one of the most flexible elements in HTML. It is similar to that of the radio input, that is, only one item can be selected from a group of items by default. However, when the multiple attribute is used with the <select> element, we can enable the selection of multiple options from the list.
Multiple List Selections. Adding the multiple attribute to <select> allows the user to select more than one option. The user will need to hold down the ctrl or cmd key to select more than one option in the list, so you will need to add some explanatory text.
To select multiple options, hold down the Control (Ctrl) key if you are using a PC system or the Apple key if you are using a Macintosh system, while you click on the several options that you wish to select.
...the newly selected items are not adjusted so as to contain the selected="selected" attribute...
Right. You'll also note that the value
attribute on an input
isn't updated when the user updates its value (e.g., if you look at outerHTML
).
This is just how things work. It's not a bug or something you're doing wrong. The runtime state of the control just isn't reflected in the HTML attribute model of the element.
What is the expected behavior?
This is the expected behavior. If you want to know which items are selected, don't look for attributes, look at the selected
property (not attribute) of the option.
If you want an array of the selected HTMLOptionElement
instances:
var selected = Array.prototype.filter.call($("id_form-0-project")[0].options, function(option) {
return option.selected;
});
If you want the actual values, combine it with .map
:
var selected = Array.prototype.filter.call($("#id_form-0-project")[0].options, function(option) {
return option.selected;
}).map(function(option) {
return option.value;
});
You can, of course, easily wrap that up into your own minimal jQuery plugin:
jQuery.fn.selectedValues = function() {
if (!this[0] || !this[0].options) {
return undefined;
}
return Array.prototype.filter.call(this[0].options, function(option) {
return option.selected;
}).map(function(option) {
return option.value;
});
};
then
var values = $("#id_form-0-project").selectedValues();
Your (good) question highlights one of the (many) dark corners of how the DOM and HTML serialization and browsers have evolved over the years. No one would have designed this. :-) And yet, quirks and all, it works surprisingly well.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With