<input> should use both the label and value from <options> when filtering/displaying based on a <datalist>
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
People
(Reporter: karlsson, Unassigned)
Details
Attachments
(1 file)
|
296 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0
Steps to reproduce:
I created a form with completion suggestions using <input>, <datalist> and <option> elements.
https://codepen.io/enjikaka/pen/XWWPOrJ
Actual results:
All the HTMLOptionElements I added a label attribute on did then not show up in the completion suggestions popup when I wrote in the rendered HTMLInputElement.
Expected results:
All HTMLOptionElements should be listed there, even if thay have a label. The label should also be listen as a sub text to the option value.
https://html.spec.whatwg.org/multipage/form-elements.html#the-datalist-element says:
Each option element that is a descendant of the datalist element, that is not disabled, and whose value is a string that isn't the empty string, represents a suggestion. Each suggestion has a value and a label.
the word "label" in that text links to https://html.spec.whatwg.org/multipage/form-elements.html#concept-option-label which says:
The label attribute provides a label for element. The label of an option element is the value of the label content attribute, if there is one and its value is not the empty string, or, otherwise, the value of the element's text IDL attribute.
Furthermore, https://html.spec.whatwg.org/multipage/input.html#the-list-attribute says:
If there is a suggestions source element, then, when the user agent is allowing the user to edit the input element's value, the user agent should offer the suggestions represented by the suggestions source element to the user in a manner suitable for the type of control used. If appropriate, the user agent should use the suggestion's label and value to identify the suggestion to the user.
This links to the same definition of "label".
I think this makes it clear that the behavior of ignoring the contents if the label attribute is present is correct.
I'd also note that the label attribute was introduced in HTML 4, I believe as a way to provide backwards-compatibility for implementations that didn't support the optgroup element. The idea was that implementations that supported optgroup would support label, and if a label was present they would ignore the text contents of the option. Older implementations would instead use the text contents of the option since they didn't know about label. So the intent of label was always something that replaced the textual contents of the option element.
|
Reporter | |
Comment 3•6 years ago
|
||
I did some further testing. I initially thought that Firefox did not render the suggestion AT ALL. But it does, it just uses the label instead of the value when querying suggestions.
As you can read in the quote from the spec there, it cleary says:
"user agent should use the suggestion's label and value to identify the suggestion to the user"
Both the label and value should be used to query for suggestions to show!
The issue here is that Firefox only uses the label if set.
The label attribute is used to describe the suggestion to the end user.
Take this example:
<input list="browsers" placeholder="Choose favourite browser...">
<datalist id="browsers">
<option>Chrome</option>
<option label="A browser with broken labels">Firefox</option>
</datalist>
In Firefox you would not be able to type "F" and get Firefox as a suggestion here. You'd have to write something to match "A browser with broken labels".
|
|
Reporter | |
Comment 4•6 years ago
|
||
Chrome: https://i.imgur.com/STpzUO0.png
Firefox: https://i.imgur.com/gnbNwym.png
(In reply to Jeremy Karlsson from comment #3)
As you can read in the quote from the spec there, it cleary says:
"user agent should use the suggestion's label and value to identify the suggestion to the user"
The "value" there links to the value attribute, which is the identifier used for form submission. That's a third concept that hasn't previously been mentioned in this bug. For both <option label=abc value=xyz>text</option> and <option value=xyz>abc</option> the label is "abc" and the value is "xyz".
OK, I guess you're right in that case where there is no value attribute, though.
|
|
Reporter | |
Comment 8•6 years ago
|
||
(In reply to David Baron :dbaron: 🏴 ⌚UTC-8 from comment #5)
(In reply to Jeremy Karlsson from comment #3)
As you can read in the quote from the spec there, it cleary says:
"user agent should use the suggestion's label and value to identify the suggestion to the user"
The "value" there links to the
valueattribute, which is the identifier used for form submission. That's a third concept that hasn't previously been mentioned in this bug. For both<option label=abc value=xyz>text</option>and<option value=xyz>abc</option>the label is "abc" and the value is "xyz".
Yes. But just like label, value also falls back to text IDL when not explicliy defined. That does however not change that fact that Firefox displays the suggestion wrongly, by not identifying suggestion using both the value and label attribute.
<option value="firefox" label="Mozilla">Firefox</option> = { value: "firefox", label: "Mozilla" }
<option label="Mozilla">Firefox</option> = { value: "Firefox", label: "Mozilla" }
<option>Firefox</option> = { value: "Firefox", label: "Firefox" }
[
'<option value="firefox" label="Mozilla">Firefox</option>',
'<option label="Mozilla">Firefox</option>',
'<option>Firefox</option>'
].map(s => document.createRange().createContextualFragment(s).children[0]).map(({ value, label }) => ({ value, label }));
The rendered suggestion box and the live filtering in it informationssystem wrong, but Mozillas JS engine correctly specifies the data.
The test above gives the same results in Firefox and Chrome.
|
|
Reporter | |
Comment 9•6 years ago
|
||
Doesn't look like I can edit my comment above but my MacBook autocorrect "is" to "informationssystem". Sorry about that typo.
I agree your analysis was correct (see my comment 6), but there's another bug on this.
|
|
Reporter | |
Comment 11•6 years ago
|
||
Cool. Didn't find that when opening this. Maybe because I wasn't 100 % sure what the entire issue was.
Let's hope 869690 gets fixed soon!
Description
•