Datalist multiple suggestion

In several places where a custom version of <datalist> is implemented, it is used to provide suggestions multiple times, namely each time users insert one of the listed values or when a specific “separator” character (comma, dot, space, hyphen, pipe) is typed. Just think about social network tag systems, or even in the “choose optional tags” box under new topics here on WICG.

Unfortunately, the suitable form control for this kind of input is type=text, which cannot have a multiple value. This is correct, because text input accepts free-form text: a separator can be an input character as well and this cannot be foreseen.

But I strongly believe that this should be modified. In particular, I would suggest two changes:

1. The possibility to indicate a character used as separator for the control
2. The possibility to show the suggestion list when said separator is typed.

As I said, the first is necessary: this way programmers can specify what separator(s) to use, employing characters not used in suggestions. It should be discussed whether UAs are expected to send control data as a single field or as a collection (the same way a multiple <select> is expected to work). The second, which is the core of my proposal, can be achieved in two ways:

• Natively: the browser resets list filter and shows it when separator character is typed.
• As API: the form control could really use a method to show the list itself (and maybe filter it). This way authors could replicate initial datalist behavior on request (namely when the separator is typed).

What do you think? Is it viable?

I think an additional use case to consider is for textarea (multi-line input)–such as when entering people tags in this form (@person) or #tag. These aren’t necessarily “separator” characters but special “trigger” characters used to make the datalist re-appear. Interestingly, you get a different datalist for @ than for #.

This could introduce a totally different yet extremely interesting scenario.

A datalist could be designed by a specific “trigger character” like this:

<input name="labels" list="tags hash" />
<datalist id="tags" char="@">
  <option value="foo" label="Foo McFoo" />
  <option value="bar" label="Bar Barrson" />
</datalist>
<datalist id="hash" char="#">
  <option value="int" label="Interest" />
  <option value="pas" label="Passion" />
</datalist>

Each datalist is labeled by a different character. Every time that character is typed in the associated control, the alternatives for that list are shown. Issues:

1. Is it necessary to type that character even when the field is empty? If so, datalists lose some of their immediacy.
2. It becomes really useful only when more than one datalist can be associated to the same form control, which in itself is not a bad idea (after all, ids can be separated by space).

Just one note: unfortunately datalists cannot be associated to textareas as of today. Were that the case, everything would be much more natural - textarea definitely has its own separator: line feed. Every time user types newline, suggestions could appear again.

EDIT: needless to say, the different suggestions can be implemented in the same datalist, just starting each value with the appropriate trigger character. As most UAs filter suggestion using the input already inserted by users, typing an @ will maintain only the suggestions starting with an @.

<input name="labels" list="tags" />
<datalist id="tags">
  <option value="@foo" label="Foo McFoo" />
  <option value="@bar" label="Bar Barrson" />
  <option value="#int" label="Interest" />
  <option value="#pas" label="Passion" />
</datalist>

In that sense, the simple “separator way” remains the most viable solution IMHO.

@travisleithead what would you prefer, datalists connected to textareas or a separator/trigger specified on the input element? Also, I don’t know how to gather attention on this.

I think even in the textarea case, a specified separator character would be useful, as assuming that newline is the separator character reduces the number of useful scenarios which I think could be equally applied to single-line input as well as multi-line input. I don’t know all the complexities around why datalist doesn’t work for textarea, but a polyfil for this idea might help draw some of them out.

assuming that newline is the separator character reduces the number of useful scenarios which I think could be equally applied to single-line input as well as multi-line input

I don’t actually understand how that is reduced, apart from the interface dimension, but as far as I know textareas can be scrolled. I thought about that because datalist input cannot contain a newline character - but perhaps this limitation is simply inherent to the fact that suggestions are meant for inline text input. So, should textarea suggestions allow newline?

I doubt that the fact <datalist> cannot be associated to textareas has any technical complexity. I rather think it is due to the limited use cases datalist was conceived for.

However, I’ll try and patch out something to test it.