<datalist> displaying both label and values for option elements is a little confusing

[joshdales]

What is the issue with the HTML Standard?

When using a datalist it is not obvious reading the spec that both the label and value will be shown, and even then that value takes precedence when displayed. When I use an option in a select element I don't see the value I only see the label, but when used in a datalist the value is always present and takes a high emphasis over the label.

I know that the spec is clear that the datalist is distinct from a select element however it does not mention anything about this and as they both use option elements I would have expected the behaviour to be closer to each other.

I've used this before and it's always found this behaviour slightly confusing and it's caused a few problems. As I didn't want to show the value just the label (like a select) but wanted the input & datalist to function as a select-like element that you can type in. As such I just had to just display the label text and then match that to the matching value with JS once it had been selected, rather than just rely on the value.

[annevk]

While user agents can tweak what is presented, the script-observable behavior cannot be changed without some kind of additional opt-in feature.

But perhaps steering it all towards a list of values is best as an end user is able to change them afterwards after all.

[joshdales]

That makes sense - and I think was a misunderstanding on my part when I first used it. And I think that was probably because I expected it to be behave more like the option list in a select.

I wonder if it might be worth more explicitly calling that out?

[annevk]

I agree that this is confusing.

I think at this point we cannot change this and maybe web developers should mainly use value and leave label alone.

When both value and label are given, I think both need to be presented to the end user as otherwise they don't understand why clicking "Netherlands, the" in a list of countries results in "NL". (Though that is also a rather strange end user experience, which brings me back to my first point about maybe not doing this.)

Interestingly Firefox does not show the value to the end user when both value and label are present, which might make end users wonder why their selection changed so drastically.

cc @emilio @smaug---- @mfreed7 @josepharhar @pxlcoder @whatwg/forms

[scottaohara]

when i was doing some tests and html aam work on customizable select, i had looked at how options within select and the customizable select differed from options within datalist. I was more focused on the variants in behavior when someone declared both text within the option and a label... but per this issue, i see that value now needs to be considered as well.

Beyond what's mentioned here, I noticed in my testing that chromium browsers are the only one that will expose all the text of an option (regardless of its origin) to the accessibility tree. Safari visually exposes the text from 2 of the 3 sources, but only the text that is rendered 'first' is read by voice over. I made an issue on HTML AAM that needs to be picked up to standardize how the second visible label is exposed to the accessibility tree - w3c/html-aam#568 (ideally this would all be done together).

IMO, I'd expect the initial text of the option as is the accName, and the secondary text becomes a description - since the visual rendering in chrome/edge give visual priority to the first line of text. If there is any visual difference in safari's rendering, my eyes cant distinguish it. they look more like separate options to me, until trying to select one and then i see both get the background highlight. But more on this in my comparison between chrome/safari below.

as noted, firefox only renders one item (either the label's value or the text of the option) in the datalist popup

so per the following markup:

<datalist id=x>
  <!-- 1 --><option>T</option>
  <!-- 2 --><option label=L></option>
  <!-- 3 --><option value=V></option>
  <!-- 4 --><option label=L value=V>T</option>
  <!-- 5 --><option label=L>T</option>
  <!-- 6 --><option label=L value=V>T</option>
</datalist>

Browsers display them / return the value as:

Firefox

1. Visible label = "T" | "T" returned to text field upon selection
2. Visible label = "L" | nothing is returned to the text field upon selection
3. Visible label = "V" | "V" returned to text field upon selection
4. Visible label = "L" | "V" returned to text field upon selection
5. Visible label = "L" | "T" returned to the text field upon selection
6. Visible label = "T" | "V" returned to the text field upon selection

Safari, Chrome and Edge

1. Visible label = "T" | "T" returned to text field upon selection
2. this option is not rendered in a datalist.
3. Visible label = "V" | "V" returned to text field upon selection
4. Visible label = "V, L" | "V" returned to text field upon selection
5. Visible label = "T, L" | "T" returned to the text field upon selection
6. Visible label = "V, T" | "V" returned to text field upon selection

Safari - Only the first of the 2 potential strings in the visible label of the option is announced as its accName by VoiceOver.
Chrome/Edge - The full visible label (the 2 text strings) is exposed as the accName of the option.

Though Safari doesn't expose all the visible information in the option - IMO, it makes sense in only exposing the first part of the label as the name - since it is what will be returned to the text field when selecting an option. While Chrome/Edge expose both as the accName, it might lead to some believing the value that will be returned is "X Y" instead of just "X"- which is why i think it makes more sense to expose the second part of the label as the "description" rather than as part of the name.

i hope this breakdown comparison helps people decide what to do here. Especially since whatever decision gets made with issue will impact how to move forward with the HTML AAM issue I referenced. And, since this behavior differs from how options/values are handled for select - an update to HTML AAM needs to be made to identify that options within a select do not use value in their accName calculation - but within a datalist the value of an option may end up being the most important contributor from HTML to the visible label / accName...