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.
Related
Consider the code below that I copied from the MDN web docs:
<label for="temp">Choose a comfortable temperature:</label><br />
<input type="range" id="temp" name="temp" list="tickmarks" />
<datalist id="tickmarks">
<option value="0"></option>
<option value="25"></option>
<option value="50"></option>
<option value="75"></option>
<option value="100"></option>
</datalist>
As you can see the result is a nice looking range with tickmarks. However, when you try to select the value that is very close to the tickmark value, the range input will snap to that value when using a mouse-drag as input. One can use a workaround to use the keyboard to get those values, but this is not an intuitive or accessible one. This makes it in some cases impossible to select those values and is therefore not what I need since those values are valid options too.
Reading the documentation on those MDN web docs:
The values provided are suggestions, not requirements: users can select from this predefined list or provide a different value.
Clearly I am experiencing something different here, at least for mouse-drag input that is. I have tried this code snippet on both Chrome and Firefox to rule out any browser implementation inconsistencies.
How can I add an input range with tickmarks while not including the snapping?
What's the purpose of the label attribute in the <option> tag in HTML5?
All the spec has to say is:
Specifies a label for the option.
MDN provides an explanation I cannot understand:
This attribute is text for the label indicating the meaning of the
option. If the label attribute isn't defined, its value is that of the
element text content.
Usage note: the label attribute is designed to contain a short label
typically used in a hierarchical menu. The value attribute describes a
longer label designed to be used near a radio button, for example.
I wrote a simple case I thought that could shed some light:
<select name="country">
<option value="ES" label="Spain's label">Spain</option>
<option value="FR" label="France's label">France</option>
</select>
... and only found that browsers seem to:
Ignore it (Firefox 26)
Completely replace tag content with it (Explorer 11, Chrome 32, Opera 12)
What is the attribute meant for?
Note: original question assumed the attribute was new. That's incorrect. It's only been enhanced due to newer tags introduced in HTML5.
In practice, it is meant for use inside a datalist element. The idea is that when browsers that do not support this element encounter it, they render its content, by normal principles, and if you want that fallback content to be empty, you need to use elements with empty content there. The label attribute lets you specify a human-readable string for an option, and modern browsers still implement the datalist with option elements properly.
Consider the following example in HTML5 CR:
<label>
Sex:
<input name=sex list=sexes>
<datalist id=sexes>
<option value="Female">
<option value="Male">
</datalist>
</label>
It is implemented so that there is just the text box, but if you type “f” there, the modern browsers suggest “Female”. (There is differences in details here, but that’s not relevant to the question.) Here you don’t need the label attribute.
But if you wanted to have values like 2 and 1 (the ISO/IEC 5218 standard codes for sexes) in the submitted form data, instead of strings “Female” and “Male”, what would you do? Inside a select element you could use <option value=2>Female</option>, but inside a datalist, that would result in the string “Female” being displayed by old browsers, and that would look odd.
Using the label attribute, you can write the datalist element as follows:
<datalist id=sexes>
<option value="2" label="Female">
<option value="1" label="Male">
</datalist>
This is meant to use human-readable words in the user interface and to submit the coded value 2 or 1 as part of form data. In practice, it does not work quite that well. The browser also has to show the coded value, since that’s what will appear in the textbox when the user selects a suggestion made by a browser. Different browsers have solved this in different ways, all with some drawbacks. E.g., on IE, focusing on the text box opens a menu with the alternatives “Female” and “Male”, which is fine, but then, if you click on “Female”, the menu closes and the character “2” appears in the box. It is difficult to say how browsers should deal with this. Anyway, this is where the label attribute is meant to be used.
Looking at this: http://blog.paciellogroup.com/2012/08/notes-on-html5-accessibility-support-in-ie-10/
It's looks like it's more used when you define a separate <datalist> for use as a list for an input.
My other thoughts are around usage for screen readers, however, I can't find any evidence of that.
Remember that <option> isn't limited to use in a <select> element, therefore some properties are more useful when included as part of <optgroup> et al.
Hope this helps.
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
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>
What is the proper way (standards compliant) way to add selected, disabled and similar attributes to <input> elements in HTML?
I have seen:
<input type="text" disabled>
<input type="text" disabled="disabled">
<input type="text" disabled="yes">
As far as I can tell, they all work, regardless of what the attribute's value is.
What is the right way to do this?
disabled is a boolean attribute.
disabled="disabled" is the correct form; disabled alone is shorthand allowed in HTML.
From On SGML and HTML:
Boolean attributes may legally take a single value: the name of the attribute itself (e.g., selected="selected").
In HTML, boolean attributes may appear in minimized form -- the attribute's value appears alone in the element's start tag. Thus, selected may be set by writing:
<OPTION selected>
instead of:
<OPTION selected="selected">
Authors should be aware that many user
agents only recognize the minimized
form of boolean attributes and not the
full form.