Open Bug 869690 Opened 7 years ago Updated 2 months ago

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

Categories

(Core :: Layout: Form Controls, enhancement, P2)

enhancement

Tracking

()

People

(Reporter: brunoaiss, Unassigned)

References

Details

(Keywords: uiwanted)

Attachments

(5 files)

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
Component: General → DOM: Core & HTML
Product: Firefox → Core
Component: DOM: Core & HTML → Layout: Form Controls
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.
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.
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...
Summary: Implement datalist GUI as w3c suggests → Always show the @value for datalist options even when they have a label (show both the label and the value)
It might actually not be, at all, the best UI, but it is a better UI than firefox's current UI, I believe.
Keywords: uiwanted
uiwanted means that you need an idea for an ui or that you need someone to make the required UI to apply this?
It means that a ui designer needs to sit down and decide what the right ui is.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
No one wants to think?
The spec has been updated to recommend displaying both the value and label: https://html.spec.whatwg.org/multipage/forms.html#attr-input-list
This needs some ux feedback. To me the spec is now surprising, but I definitely shouldn't say anything about UI :)
Flags: needinfo?(philipp)
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).
Flags: needinfo?(philipp)
Which webkit version are you using to test?
Did you try blink too? If so, which version?
Flags: needinfo?(philipp)

Clearing needinfo as Phlsa is no longer at Mozilla

Flags: needinfo?(philipp)

Who, from UX, may I needinfo?

Flags: needinfo?(sledru)
Flags: needinfo?(sledru)
Version: 23 Branch → unspecified

Let me find out!

Attached image 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

Attached video datalist.mp4

Here's a video going over the issues.

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.

(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.

(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.

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.

(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.

Duplicate of this bug: 1596066
Priority: -- → P2
Duplicate of this bug: 1596066

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.

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.

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?

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

You need to log in before you can comment on or make changes to this bug.