select vs multiple with required attribute behaves inconsistently - html

I have a basic form like so:
<form id="test-form">
<select id="multi" name="mymulti" multiple required>
<option value="">Choose a different Option</option>
<option>Foo</option>
<option>Bar</option>
<option>Baz</option>
</select><br>
<select id="single" name="myselect" required>
<option value="">Choose a different Option</option>
<option>Foo</option>
<option>Bar</option>
<option>Baz</option>
</select> <br>
<input type="submit">
</form>
The key point here is two selects, both required, but one is multiple and the other is not.
If you choose the default options (note you actually have to click on them), and then submit the form, it will tell you that the single select is required, but not the multiple select.
I looked at the relevant portion of the html5 spec, and although there is some talk about how the required select interacts with placeholder elements, I don't see anything about how multiple+required behaves.
The above behaviour is only in Chrome, other browsers seem to behave the same for both types. My question is, why? It seems... inconsistent. I understand how to work around it with some javascript, just not why I would have to? Can anyone explain the rationale behind this?
Demo (remember to actually choose the placeholder options).

Chrome is acting right here. While implementation in FF is simply simpel. But chrome's implementation does not only follow the spec, it is also simply logic. If a mutliple or size > 1 select is used, there is no placeholder by definition. And without a selected attribute there is indeed nothing :checked (i.e.: selected) initially.
In case of a single select with size=1. The select > option:first-child with an empty value is the placeholder option. And a single select has always one option :checked/selected.
Here is a definition of placeholder option in JS: https://github.com/aFarkas/webshim/blob/gh-pages/src/shims/form-shim-extend.js#L88-94 and here a definition of valueMissing for select: https://github.com/aFarkas/webshim/blob/gh-pages/src/shims/form-shim-extend.js#L128-130

Related

Input text Field inside `<select>` tag

I am creating a dropdown with AngularJS.
here is the code..
<div class="col-md-9">
<input type="text" placeholder="Enter Module" list="names"
ng-model="data.Name" />
<select id="names" class="form-control" ng-model="data.Name"
ng-change="SetCategory(data.Name)" name="name">
<option value='' disabled selected>------------- select an option ----------</option>
<option ng-repeat="e in BrData | filter:data.Name "
value="{{e.Name}}">{{e.Price}}</option>
</select>
</div>
NOTE: List is Dynamic and i am using AngularJS to get data.
I need To create a searchbar inside select tag.
But Input tag can't nested in select tag.What should I do?
You can use typeahead from UI Bootstrap: https://angular-ui.github.io/bootstrap/#!#typeahead
Or if you need more advanced features along with search like multi-select, select all, deselect all, disable options, keyboard controls and much more try this: http://dotansimha.github.io/angularjs-dropdown-multiselect/docs/#/main
The way I see it, there are three options here.
Option One - Input outside the dropdown
Get the input outside the dropdown, and filter the values based on that value from the outside. I know that this is not your intended functionality exactly, but it would save you some trouble.
Option Two - Use some kind of third party dropdown library
As Mohd mentioned https://angular-ui.github.io/bootstrap/#!typeahead is a good fit and UI select too
Option three - Create something of your own
It need not even be using <select> tag. This is by far the most difficult, but also the most customizable and suitable for individual needs. The select tag will not be used as it does not support input inside of it, so some high end css will need to be used, as well as some backwards compatibility multiple browser testing that the already made libraries have already done.
Dealing with the <select> nightmare
From the Docs:
<select> Element Technical summary1
Permitted content: Zero or more <option> or <optgroup> elements.
Tag omission: None, both the starting and ending tag are mandatory.
Permitted parents: any element that accepts phrasing content
The short answer is that <input> elements can not be placed inside <select> elements.
<datalist> Element2
The datalist element is intended to provide a better mechanism for this concept.
<input type="text" name="example" list="exampleList">
<datalist id="exampleList">
<option value="A">
<option value="B">
</datalist>
For more information, see
HTML combo box with option to type an entry
MDN Learn HTML Forms - Dealing with the select nightmare
Use select2 as a dynamic option instead of HTML select option:
here is link for select using js:
https://select2.org/tagging

Chrome 77 caching <select> selected option, even with autocomplete="off"

If a <select> element has a selected option, Chrome will ignore that selected option even if autocomplete="off" on the <select> element when using the browser's "navigate back" functionality. One workaround I have found is wrapping the select in a <form>, but I don't want extraneous forms in my html.
Question: Is there a way to fix this in Chrome without wrapping in a form element? (This behavior does not occur in Firefox, haven't tested other browsers)
To reproduce, using Chrome 77:
1.) Visit this jsfiddle, and change both selects to "One". Note that "Two" is the selected option for both, so when the page loads this is what should be selected in both elements
2.) Click on the link to google (page navigation won't actually occur, jsfiddle output can't actually navigate to webpages)
3.) With your mouse having clicked in jsfiddle output, click the browser's back button
4.) You'll note that the select element which is wrapped in a form has the correct element selected by default, "Two". The select element which is not wrapped in a form has the incorrect element selected, "One"
https://jsfiddle.net/m5hg8n40/1/
<!-- chrome ignores 'selected' -->
<select autocomplete="off">
<option value="1">One</option>
<option value="2" selected>Two</option>
</select>
<br><br>
google.com
<br><br>
<!-- chrome obeys 'selected' -->
<form autocomplete="off">
<select>
<option value="1">One</option>
<option value="2" selected>Two</option>
</select>
</form>
MAC OS Catalina 10.15
 Browsers
Google Chrome Version 77.0.3865.120 (Official Build) (64-bit)
Safari Version 13.0.2 (15608.2.30.1.1)
Firefox 70.0
 Actions tested:
Onload the jsfiddle i see both with the two option selected
If i click google link and go back, both keeps two selected
If i modify first select (without form) to one, go google and go
back, it keeps the one selected
If i modify the second select (with form) to one, go google, and go
back, it will show the two option selected
So as far as i see.
On load works for both, but the window History treats slightly different both input select, if they are wrapped or not in a <form>tag
One will keep the last action executed, and the other will take priority of the form to reset its inputs to the default state.
Excepcion: Firefox treat both with the same behavior (like without the form)
For me it seems legit to use the tag there if you need it, they can be use to collect data even if they are going to be used locally or remotely.
( is not worse than pages having 1047248 <div>'s everywhere and zero semantic HTML ) so its really up to you i think. And if you need to store data in another way you could use LocalStorage
I think you can't do anything without js.
<body onload="document.querySelector('select').value = document.querySelector('select [selected]').value">
<select>
<option value="1">One</option>
<option value="2" selected>Two</option>
</select>
<br><br>
google.com
<br><br>
<form autocomplete="off">
<select>
<option value="1">One</option>
<option value="2" selected>Two</option>
</select>
</form>
</body>

HTML5 Datalist with Readonly Input, is it valid?

I have in my application a html5 datalist like so:
<input type="text" list="mydatalist" />
<datalist id="mydatalist">
<option>Option 1</option>
<option>Option 2</option>
<option>Option 3</option>
</datalist>
It works very well until I change the input element to readonly like so:
<input type="text" list="mydatalist" readonly />
Then focusing on the input element now does NOTHING...
I have arrived at the assumption that by the specs, a text input with list attribute should not also be readonly. Almost like saying, "If you desire readonly, then use a select tag". To complicate this matter some more, I feel almost certain that this setup (with readonly) once worked on this application. Unfortunately, the answers did not come obvious during my initial web search.
Is my assumption correct, or have I missed something?
Datalist vs Select:
I guess this is what you want, but there is no comparison. Datalist is different, Select is different.
datalist is used for autopopulating results from the list, based on user input, while select doesnt do any magic, it just shows all options it has.
so this makes clear that there shouldnt be any preselected value in datalist(as it is used to auto populate, on user interaction). thus it cant be readonly
select on other hand is different, it can have a default value, thus it can be readonly.
And yes what you said: "If you desire readonly, then use a select tag", yes, according to me its true, coz you cant set anything as selected in datalist, but you can in select.

HTML <select>, not <select multiple>: behavior when more than one option is selected

In this simple jsfiddle (code below), I have a regular <select>, not a <select multiple>, with two options having the selected attribute. In Chrome 39, I see "d" selected. Apparently the behavior is to select the last of the "selected" options, which seems logical. Is this a behavior I can count on across browsers?
<select>
<option value="a">a</option>
<option value="b" selected>b</option>
<option value="c">c</option>
<option value="d" selected>d</option>
</select>
A select element whose multiple attribute is not specified must not
have more than one descendant option element with its selected
attribute set.
source w3.org
So it's not valid HTML and therefore the browsers' behavior is not predictable. If you've create these selected options via Javascript, you should maybe handle your desired behavior via JS as well.

Browser caching select tag state and ignoring selected="true"

I'm rendering a drop down box that contains a currently selected value using selected="true".
<select id="dropDown">
<option selected="true" value="1">value2</option>
<option value="2">value3</option>
<option value="3">value4</option>
</select>
Initially the selected value corresponds to the selected="true", but if I play around with the drop down box and then refresh the page the selected="true" is ignored and the displayed value is the last one I chose. I tried using selected="selected" with the same results.
Thanks for your help.
Change your select field to <select id="dropDown" autocomplete="off">
For best browser support it's actually (although it seems so dumb) better to use
autocomplete="nope"
To quote MDN:
In some cases, the browser will keep suggesting autocompletion values
even if the autocomplete attribute is set to off. This unexpected
behavior can be quite puzzling for developers. The trick to really
forcing the no-autocompletion is to assign a random string to the
attribute [...] Since this random value is not a valid one, the browser will give
up.
It's a binary value, not an attribute (for some reason). Use:
<option selected="selected" value="1">value2</option>
or:
<option selected value="1">value2</option>