Should we use option's label or value to match user's input in list attribute? #1811
Labels
Comments
|
This is very related to #1087. As I stated there, we don't specify UI in the spec, so implementations can use label, value, or both if they want for display. There's the separate question of how searches are performed, and there's not much agreement there. |
annevk
added
compat
|
Yeah, this is very much up to each user agent to decide what the optimal UI is for their users. I do hope that over time as we learn more we can add some guidance to the specification and converge implementations as otherwise developers will just end up using libraries with deterministic behavior instead. |
domenic
added a commit
that referenced
this issue
Sep 28, 2016
As discussed in both #1811 and #1087, users, web developers, and implementers find the spec's current vague phrasing around datalist UI confusing. This has led to great implementation divergence, as documented in the table in #1087. (That table also does not capture the substring vs. prefix matching divergence.) This attempts to provide more normative UI guidance and resolve the issue, essentially taking the union of current display and search choices. This will require changes from all browsers if they wish to apply these suggestions. Fixes #1811; fixes #1087.
domenic
added a commit
that referenced
this issue
Oct 13, 2016
As discussed in both #1811 and #1087, users, web developers, and implementers find the spec's current vague phrasing around datalist UI confusing. This has led to great implementation divergence, as documented in the table in #1087. (That table also does not capture the substring vs. prefix matching divergence.) This attempts to provide more normative UI guidance and resolve the issue, essentially taking the union of current display and search choices. This will require changes from all browsers if they wish to apply these suggestions. Fixes #1811; fixes #1087.
domenic
added a commit
that referenced
this issue
Oct 14, 2016
As discussed in both #1811 and #1087, users, web developers, and implementers find the spec's current vague phrasing around datalist UI confusing. This has led to great implementation divergence, as documented in the table in #1087. (That table also does not capture the substring vs. prefix matching divergence.) This attempts to provide more normative UI guidance and resolve the issue, essentially taking the union of current display and search choices. This will require changes from all browsers if they wish to apply these suggestions. Fixes #1811; fixes #1087.
domenic
added a commit
that referenced
this issue
Oct 28, 2016
As discussed in both #1811 and #1087, users, web developers, and implementers find the spec's current vague phrasing around datalist UI confusing. This has led to great implementation divergence, as documented in the table in #1087. (That table also does not capture the substring vs. prefix matching divergence.) This attempts to provide more normative UI guidance and resolve the issue, essentially taking the union of current display and search choices. This will require changes from most browsers if they wish to apply these suggestions. Fixes #1811; fixes #1087.
alice
pushed a commit
to alice/html
that referenced
this issue
Jan 8, 2019
As discussed in both whatwg#1811 and whatwg#1087, users, web developers, and implementers find the spec's current vague phrasing around datalist UI confusing. This has led to great implementation divergence, as documented in the table in whatwg#1087. (That table also does not capture the substring vs. prefix matching divergence.) This attempts to provide more normative UI guidance and resolve the issue, essentially taking the union of current display and search choices. This will require changes from most browsers if they wish to apply these suggestions. Fixes whatwg#1811; fixes whatwg#1087.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://html.spec.whatwg.org/multipage/forms.html#the-list-attribute
It 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. The user agent may use the suggestion's label to identify the suggestion if appropriate."
However, from the example in type=url, it is using value to match user's input, and it's a substring matching.
Currently, Firefox uses label, Edge uses value and Chrome, in its latest version, uses label and value. Should the spec be clearer so that user agents behave the same?
@annevk
The text was updated successfully, but these errors were encountered: