869690 - Always show the @value for datalist options even when they have a label (show both the label and the value)

Status: NEW

(Toolkit :: Autocomplete, enhancement, P2)

Description

[brunoais]

Attachment: The image that represents what I mean. I'm just backing it up.

The GUI that firefox implemented is different of what w3c suggests which is the one that webkit implemented.

I'm requesting that you change the GUI so that it matches the one suggested by w3c.

Here's where I found an image representation and a small text giving some extra information

http://www.w3.org/html/wg/drafts/html/master/forms.html#url-state-%28type=url%29

http://www.w3.org/html/wg/drafts/html/master/images/sample-url.png

Comment 1

[Boris Zbarsky [:bzbarsky]]

Given the lack of a testcase, it's hard to tell exactly what this bug is about..  In particular, what's missing is how the observed behavior differs from the desired behavior.

Comment 2

[brunoais]

Attachment: An image exemplifying how firefox displays the label and the value in a datalist

OK: more information:

Firefox implements datalist by placing to all the option@value in the suggestion list under the input. That is according to the spec.

The difference is that if I use a option@label, that text replaces the text that belongs to the suggestion but it shouldn't.

What should happen in the "suggestion rectangle" (I'm sorry but I don't know the name of that thing that appears under the input tag giving suggestions when the user starts typing) is to display first the suggestions where the @value is aligned to the left and the @label is, in the same line, aligned to the right.

In firefox, the @value is replaced by the @label if the @label exists.

I attached an example source code and what it gives as a result.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So here's what the spec has to say in actual normative text:

  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. The user agent may use the suggestion's label to identify the
  suggestion if appropriate.

It happens that the spec is using a screenshot taken in a particular browser as part of its non-normative text to illustrate what one possible UI might be.  It's not obvious that this is the best possible UI...

Comment 4

[brunoais]

It might actually not be, at all, the best UI, but it is a better UI than firefox's current UI, I believe.

Comment 5

[brunoais]

uiwanted means that you need an idea for an ui or that you need someone to make the required UI to apply this?

Comment 6

[Boris Zbarsky [:bzbarsky]]

It means that a ui designer needs to sit down and decide what the right ui is.

Comment 7

[brunoais]

No one wants to think?

Comment 8

[Domenic Denicola]

The spec has been updated to recommend displaying both the value and label: https://html.spec.whatwg.org/multipage/forms.html#attr-input-list

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

This needs some ux feedback. To me the spec is now surprising, but I definitely shouldn't say anything about UI :)

Comment 10

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

The OP mentioned that Webkit uses this behavior already, but I wasn't able to reproduce it.
My main concern in showing something that has been previously hidden would be that it could surface a lot of non-human-readable data (if the developer is not expecting that the value is visible to the user).

Comment 11

[brunoais]

Which webkit version are you using to test?
Did you try blink too? If so, which version?

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Clearing needinfo as Phlsa is no longer at Mozilla

Comment 13

[brunoais]

Who, from UX, may I needinfo?

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Let me find out!

Comment 15

[Verdi [:verdi] Best to slack me]

Attachment: datalist.jpg

Ok so a quick bit of testing it looks like Firefox, Chrome and Safari all do different things. Chrome seems to follow the spec and Firefox does indeed do this weird swap of value for label mentioned in comment 2. We should fix the problem in comment 2.

(In reply to Philipp Sackl from comment #10)

My main concern in showing something that has been previously hidden would
be that it could surface a lot of non-human-readable data (if the developer
is not expecting that the value is visible to the user)

Chrome already does this so I think it may not be a problem. We can implement this but we should do it as two left-aligned columns (see attachment).

In addition, I think we're missing a dropdown control.

This MDN page is a good place to see this issue in action for yourself - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist

Comment 16

[Verdi [:verdi] Best to slack me]

Attachment: datalist.mp4

Here's a video going over the issues.

Comment 17

[Jen Simmons [:jensimmons]]

This is something we should fix. And if the spec doesn't require the best UX for this interface, then the spec should be updated. We want all the browsers to have the same implementation, and we want the spec to ask them to do what's best for users.

This kind of lack of interop is why developers use divs instead of proper HTML, like datalist, creating inaccessible sites that do not work in every browser.

Comment 18

[brunoais]

(In reply to Jen Simmons [:jensimmons] from comment #17)

This is something we should fix. And if the spec doesn't require the best UX for this interface, then the spec should be updated. We want all the browsers to have the same implementation, and we want the spec to ask them to do what's best for users.

I disagree. I believe that it's OK for each browser to have their own default GUI for each functionality.

This kind of lack of interop is why developers use divs instead of proper HTML, like datalist, creating inaccessible sites that do not work in every browser.

IMO:
Actually, the main problem with these kinds of things is actually the lack of personalization available in the webpage itself. It is the lack of being able to use certain CSS to control every detail of how each shadow DOM tag displays that leads to designers reimplementing complex tags as you mention.

Comment 19

[Šime Vidas]

(In reply to brunoais from comment #18)

I disagree. I believe that it's OK for each browser to have their own default GUI for each functionality.

I think Verdi’s video in comment 16 clearly shows that the way Firefox’s treats labels is preventing developers from using them because if labels are present, the user is no longer able to see the values nor get suggestions based on what they type (i.e., the values are not matched against the user’s input). I repeat, developers currently cannot use labels because of Firefox.

Comment 20

[Jay]

I strongly agree with comment #19 and comment #17: Firefox's current implementation of dataset values is essentially preventing developers from using dataset in this way at all, because if the behavior of an HTML feature is not consistent in at least the major browsers, developers will have to simulate it with 3rd party libraries or DIY solutions, like Jen says.

Comment 21

[brunoais]

(In reply to Šime Vidas from comment #19)

(In reply to brunoais from comment #18)

I disagree. I believe that it's OK for each browser to have their own default GUI for each functionality.

I think Verdi’s video in comment 16 clearly shows that the way Firefox’s treats labels is preventing developers from using them because if labels are present, the user is no longer able to see the values nor get suggestions based on what they type (i.e., the values are not matched against the user’s input). I repeat, developers currently cannot use labels because of Firefox.
Please read the last paragraph of my answer.

I clearly state that default UI is OK. I never stated forced UI is OK.
If you want to continue discussing that, please get me somewhere else public to continue the discussion to avoid cluttering this bug.

Comment 24

[Matthew N. [:MattN]]

I think there are times when showing the value wouldn't be horrible, like comment 0, or when the value is something the user could understand e.g.

<option label="California" value="CA"></option>

but often value is just some primary key from a database and I don't think the users should ever see that. I think an ideal UX in that case aligns with what sites use for tag autocomplete UI (similar to Gmail's To/CC/BCC fields) where the user only sees a label, the value would never be shown in the field, only a bubble with an affordance to remove that item. When I Google Image Search for "tag autocomplete ui", not a single image on the first set of results have both a label and value showing to the user.

Also, not showing @value aligns with how <option> has worked with <select> for a long time.

Comment 25

[Matthew N. [:MattN]]

Attachment: Tag autocomplete UI not exposing a separate "value"

I think there are times when showing the value wouldn't be horrible, like comment 0, or when the value is something the user could understand e.g.

<option label="California" value="CA"></option>

but often value is just some primary key from a database and I don't think the users should ever see that. I think an ideal UX in that case aligns with what sites use for tag autocomplete UI (similar to Gmail's To/CC/BCC fields) where the user only sees a label, the value would never be shown in the field, only a bubble with an affordance to remove that item. When I Google Image Search for "tag autocomplete ui", not a single image on the first set of results have both a label and value showing to the user.

Also, not showing @value aligns with how <option> has worked with <select>.

Maybe the author should be able to decide whether or not to expose the value but I don't think always showing the value is desirable in all cases.

Comment 26

[brunoais]

I think that being able not to show the value using some attribute would be the best choice.
The question then becomes: How to choose to specify to show both or just the label?

Comment 27

[Jeremy Karlsson]

I think it's important to highlight the fact that label is often in practice used as a description for the value, and does not disqualify the value from being shown if label is available. The value and label attribute are used together to help the user select the right suggestion.

The spec cleary says what should be done:

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.

The value should always be shows since that is what the user is actually selecting. And, if available, the label should also be shown to help the user in choosing a suggestion.

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>

Chrome: https://i.imgur.com/STpzUO0.png
Firefox: https://i.imgur.com/gnbNwym.png

Comment 28

[Šime Vidas]

Attachment: Labels shown in <datalist> dropdown in Safari preview

Safari Technology Preview 104 has added labels to the <datalist> dropdown.

Source: https://webkit.org/blog/10264/release-notes-for-safari-technology-preview-104/

Comment 29

[Victor Magalhães]

Attachment: Bug 869690 - Always show the @value for datalist options even when they have a label (show both the label and the value)

Comment 30

[Victor Magalhães]

Hello, there! I tried my hand at this bug with the above revision because it seemed approachable enough to learn more about the Firefox codebase, I hope it can be useful. To keep changes at a minimal, I tried to reuse similar autocomplete controls found elsewhere (the autocomplete for login, it seems). This is my second patch for Firefox, so I'm sure there will be mistakes. A screen recording of the resulting UI can be found here: https://imgur.com/a/jgYK8nT. Thanks!

Comment 31

[Victor Magalhães]

Attachment: autocomplete.gif

I figured out how directly insert a GIF here, sorry for the additional notification. Anyway, that's how the submitted revision looks like.

Comment 32

[brunoais]

(In reply to Victor Magalhães from comment #31)

Created attachment 9141662 [details]
autocomplete.gif

I figured out how directly insert a GIF here, sorry for the additional notification. Anyway, that's how the submitted revision looks like.
I suggest you add not just the different color as you did but also indent the text by some pixels. Maybe 10px is a good start.

Comment 33

[Victor Magalhães]

Thanks for the pointer, brunoais! I'm just waiting for a signal that I should continue with this, since there doesn't seem there was a consensus if it should, by the discussion.

Review ping?

Comment 34

[krystian3w]

Bug with value fixed with https://bugzilla.mozilla.org/show_bug.cgi?id=40545?

But still is no visible "drop-down" button (like as Chrome/Safari).

Comment 35

[Matthew N. [:MattN]]

(In reply to Victor Magalhães from comment #33)

Thanks for the pointer, brunoais! I'm just waiting for a signal that I should continue with this, since there doesn't seem there was a consensus if it should, by the discussion.

Review ping?

Note that review should be requested via Phabricator. I still don't think we should do this as for the reasons I said before… the one off-hand is that it doesn't align with <option in <select> and seems to be a poor workaround to a problem. We really need a tag-like autocomplete UI instead.

Comment 36

[John Flatness]

(In reply to Matthew N. [:MattN] from comment #35)

I still don't think we should do this as for the reasons I said before… the one off-hand is that it doesn't align with <option in <select> and seems to be a poor workaround to a problem. We really need a tag-like autocomplete UI instead.

I don't expect to change any minds necessarily, but here goes:

This particular argument is nonpersuasive, I think. The reason being: <input>-with-<datalist> isn't <select>, and it's different in a key respect: the actual value is what will be shown in the input box when the user selects it, unlike a <select> which always displays the labels. So built into this functionality, Firefox already is by necessity displaying the option's value here, just in the actual input box. Not displaying values in the suggestion list trades consistency in how <option> works for inconsistency in how the actual <input> works: when a label is present, the option displayed in the suggestion list does not match what's actually visibly inserted into the input.

For similar reasons, prior arguments in this thread about <option> values sometimes being internal identifiers, etc. are also nonpersuasive: those values are going to be shown anyway upon selection. So a use case with values that cannot or should not be shown to the user is not going to be using this feature regardless, whether with Firefox's current implementation or any other UA's.

A hypothetical different input type/mode/etc. that uses the datalist or another autocomplete source differently, such that labels would be displayed everywhere (a sort of modified <select> or <select multiple> in essence) would be quite valuable, but that doesn't really have bearing on what should be happening for a text input with a datalist now.

If consistency is the key concern, if anything it would be better to simply ignore datalist option labels entirely.

Comment 37

[Matthew N. [:MattN]]

(In reply to John Flatness from comment #36)

(In reply to Matthew N. [:MattN] from comment #35)

I still don't think we should do this as for the reasons I said before… the one off-hand is that it doesn't align with <option in <select> and seems to be a poor workaround to a problem. We really need a tag-like autocomplete UI instead.

I don't expect to change any minds necessarily, but here goes:

This particular argument is nonpersuasive, I think. The reason being: <input>-with-<datalist> isn't <select>, and it's different in a key respect: the actual value is what will be shown in the input box when the user selects it,

The spec doesn't require that the value is shown and it isn't the ideal UI that datalist should have. See comment 25.

Firefox already is by necessity displaying the option's value here, just in the actual input box.

It's not be necessity, it's only because no real UX effort has gone into this feature.

Not displaying values in the suggestion list trades consistency in how <option> works for inconsistency in how the actual <input> works: when a label is present, the option displayed in the suggestion list does not match what's actually visibly inserted into the input.

For similar reasons, prior arguments in this thread about <option> values sometimes being internal identifiers, etc. are also nonpersuasive: those values are going to be shown anyway upon selection.

See above, you are making an assumption about the UI which the spec doesn't require and doesn't match the ideal UX.

A hypothetical different input type/mode/etc. that uses the datalist or another autocomplete source differently, such that labels would be displayed everywhere (a sort of modified <select> or <select multiple> in essence) would be quite valuable, but that doesn't really have bearing on what should be happening for a text input with a datalist now.

Why would browsers want to support two similar UIs when they could support one great one?

If you want to show the value, you can already include it in the label now so you don't need a browser change for that.

Comment 38

[John Flatness]

(In reply to Matthew N. [:MattN] from comment #37)

The spec doesn't require that the value is shown and it isn't the ideal UI that datalist should have. See comment 25.

Firefox already is by necessity displaying the option's value here, just in the actual input box.

It's not be necessity, it's only because no real UX effort has gone into this feature.

I feel that to make this argument you have to think there's a serious chance of a major UI change to <input type="text" list="x"> such that the input doesn't display the actual current text of the value. If that's what you're suggesting then I think we're simply operating in different realities.

Not displaying values in the suggestion list trades consistency in how <option> works for inconsistency in how the actual <input> works: when a label is present, the option displayed in the suggestion list does not match what's actually visibly inserted into the input.

For similar reasons, prior arguments in this thread about <option> values sometimes being internal identifiers, etc. are also nonpersuasive: those values are going to be shown anyway upon selection.

See above, you are making an assumption about the UI which the spec doesn't require and doesn't match the ideal UX.

The spec for list/<datalist> indeed leaves the decision of what to display to UAs, though it doesn't provide similar freedom for the actual base <input type="text">, given section 4.10.5.1.2 on the text and search types states: "The input element represents a one line plain text edit control for the element's value."

Note that this was the point of my previous comment: that the input will display the underlying value, as it indeed currently does in Firefox and elsewhere.

Though if we do want to talk about the list spec, it does provide "should" guidance in section 4.10.5.3.9 that "user agents should search within both the label and value of the suggestions for matches" and "If appropriate, the user agent should use the suggestion's label and value to identify the suggestion to the user." Now, you could drive a truck through the "if appropriate" in that second excerpt (to say nothing of the "should"), but the intent of that qualifier is clearly to be taken in the context of other types. In the specific context of a text input the just-following example states: "For user agents that follow the above suggestions, both the label and value would be shown" in the suggestion area.

Firefox neither shows nor autosuggests on the values in the presence of a label (the latter being a more unquestionable contravention of the spec's "should" language).

A hypothetical different input type/mode/etc. that uses the datalist or another autosuggest source differently, such that labels would be displayed everywhere (a sort of modified <select> or <select multiple> in essence) would be quite valuable, but that doesn't really have bearing on what should be happening for a text input with a datalist now.

Why would browsers want to support two similar UIs when they could support one great one?

Firefox already supports this one, just in a uniquely poor way.

Though I don't necessarily think that "tag autocomplete" is the standard by which the UX for this feature should be judged, a mild (though not 100% analogous) counterexample to your set of examples from comment 25: the Stack Overflow tag autocomplete, which completes on the tag names (the "values") and shows the tag names in the input when selected, but also shows an additional descriptive label to explain what each tag is in the suggestion box. You also brought up in that comment the Gmail To/From/CC/etc. suggestion interface, which also shows you both a label (the contact name) and a value (the email address) in the suggestion list. Come to think of it, along those same lines another "suggestions show and suggest on both label and value" interface: Firefox's own URL bar.

My basic response to the idea of the "one great one" "ideal" UX is: that it's simply a different feature, one which doesn't eliminate the usefulness of this actual one. Even if eventually implemented, this "ideal" option is overwhelmingly likely to be a different input type, different element, and/or controlled by different attribute(s) than what we have today.

Just to make the case for "datalist as the spec suggests": I'll just say that I've used (or plan to use) <datalist> with labels for things like BCP 47 language tag inputs, where I want the display to be the actual tag, provide suggestions of common language tags in use plus a helpful hint/sanity check of the language name, plus full-text freedom for a user to specify the non-suggested "zh-CN-pinyin" value they know they really want. Or something like WMS (Web Map Service) layers, which have an identifier that every layer has to have and that I really want to foreground, but also optionally a label that can provide helpful context. Notably In both of these cases I don't want the hypothetical "ideal" where a label in the datalist changes what's shown in the input box. URLs and page titles would be another good example along those lines.

If you want to show the value, you can already include it in the label now so you don't need a browser change for that.

Point taken, though to avoid duplication in display I would now still need a browser change, just to the other browsers.

Comment 39

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:emilio, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 40

[Tom Doan]

I came here because the datalist in Firefox is not the same as the experience in Chrome in at least the following ways that I can observe:

1. In Chrome when you have both value and labelattributes, thevalueis shown on top and thelabelis shown below it (preferred). In Firefox, thelabeloverrides thevalue` if it's present.

2. In Chrome as you type it matches against both the value and the label attributes (preferred), whereas in Firefox it only matches against the label.

Hopefully Chrome and Mozilla teams can get together to agree on a uniform UX because it feels like the early days of Netscape/IE5 incompatibilities and browser-specific hacks again when it comes to datalist :'(.

Comment 41

[Tom Doan]

I just noticed a 3rd discrepancy between Firefox and Chrome datalist handling:

3. In Chrome, when a datalist <option> is dynamically added/removed, the autocomplete menu syncs in real time (i.e., the removed <option> is also dropped from the autocomplete menu). In Firefox, when an option is removed from the datalist, that entry is still displayed in the autocomplete menu.

Comment 42

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.