search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.01k stars 2.62k forks source link

datalist 'nofilter' attribute #4882

Open HarshaLaxman opened 5 years ago

HarshaLaxman commented 5 years ago

Reviving this issue from the W3C repo: https://github.com/w3c/html/issues/888

Another (personal) example of why it is useful: Using a search engine for autocomplete, and populating the datalist options with the results (https://elastic.co/guide/en/elasticsearch/reference/current/search-suggesters.html#completion-suggester) We can add an analyzer for the suggestion, so for example if we use an analyzer that strips underscores, when the user types '_ init python' we can still suggest '__init__ python'. The datalist however will filter out the search engine's suggestion.

It seems the workaround is to use a library or use a 'ul' and style it (seems Google does that)

domenic commented 5 years ago

Can you explain the issue? You've given an example, but no actual explanation of what you're looking for.

If this is about a new feature, please see https://whatwg.org/faq#adding-new-features, especially step 1 and 2.

HarshaLaxman commented 5 years ago
  1. Whenever the user types in the input, the datalist should populate with suggestions from the search index. The datalist should not filter by the input value, because the suggestions may not match the value ('init' query should suggest '__init__') Requirements: -all options in the datalist should be visible to the user, regardless of what is in the input value
domenic commented 5 years ago

It's not clear how much the user experience changes you're asking here have to do with the spec. In particular, I don't believe there's anything in the spec which would prevent browsers from implementing the experience you're asking for. Similarly, I don't believe we need to add features to the spec to support the experience you're asking for.

Rather, what you need to do is convince browsers to update their datalist implementation to work in the way you describe. This is best done with evidence that the pattern you're asking for is a widespread one, e.g. a popular library that implements it or similar.

See also https://github.com/wicg/open-ui

clydebarrow commented 4 years ago

Here's a specific use case: I have a search facility that allows partial matching on names, e.g. the input "Sara John" might result in the datalist being populated with "Sarah John", "Sara Johnson" and "Sarah Johnson" - but the displayed drop-down list (at least in Chrome) will only show the second, because the text in the search box is not a prefix of the other two.

There currently appears to be no workaround for this. A "nofilter" attribute on the datalist would provide an escape. It may well be that at the moment the exact behaviour of a browser in filtering the list is unspecified, and achieving a consensus on what that behaviour should be could be hard, but at least some way of turning off the filtering should be available.

inopinatus commented 3 years ago

My use case is different again. We collect data for sports events. Let's say this includes asking for a timing chip ID. Most have a default/preferred chip, plus a collection of others to choose from.

Naturally we pre-populate the form with their preferred chip ID, but leave the text field open in order to organically learn their collection.

When we've tried to use a datalist, to supply alternatives from their history, no-one used it. Why? Because when clicking on the dropdown arrow, the datalist is filtered already by the default value, i.e. the user just sees one item.

For a time we experimented with including the default in the option label, so it would match everything, then styling the label to disappear it. This was discarded as a terrible hack.

Why not use a select? One field is far better than two, especially for mobile devices or assistive technologies; and supporting an interaction between a text input and a select requires scripting, at which point 95% of <datalist>'s reason for being disappears.

What do you suggest? A nofilter attribute, like everyone else; however, consider that it could appear on the input, the datalist, or the options themselves. Alternatively, a hook to allow a function to decide how to filter the list.

andrewgoz commented 1 month ago

In my opinion, the mistake was for the W3C/WHATWG to encourage filtering of data lists in the first place. I would much rather not have filtering options and instead change the spec to encourage user agents to split the list display into two sections: one section showing filtered list items based on user entry (the same as widely implemented now) and a second section that shows the data list items without the items shown in the first section.