[1337shadow]

I just tried a datalist with 4 elements: https://jsfiddle.net/zguvdet0/

And it doesn't cut it for a foreign key: it can't even have a separate option value and label like the basic select ... Well, it sort of can, but then the user sees the value of the option (the related row id in the context of a CRUD) and not the label ...

Does that mean that when I choose "something" and go back to my form again i will see "123" because "123" is the id of "something" on the remote row ?

I must be doing it wrong ... otherwise, it's far from acceptable UX.

https://jsfiddle.net/zguvdet0/

[chrismorgan]

You seem almost to be deliberately fabricating problems. In this case the solution seems rather obvious: you would put the label as the value, and resolve the label back to an ID on the backend. Just as you’d be checking the ID on the backend anyway, to make sure it’s valid.

Yes, this could be a problem if the label is not unique. But if that could happen you already had problems, because how was the user supposed to tell which “ACME Inc.” they were supposed to click on?

[1337shadow]

I'm sorry to make you feel this way, I'm fine ignoring the typical customer that will not accept such an UX for the shake of the discussion, I'm fine with having unique labels even though that means that I would either have to store them in the DB, either rebuild them, for example, in the case of "<firstname> <lastname> (<email>)", I'm afraid a user could do a typo in-between selection and form submission, for example while opening the form on an existing object to modify another field (users do mis-click, and give me a call), in this case, should I be showing the input with the data that contains the typo so that the user can see it and delete the value and start over ?

Also I know users would be happier if I could display some kind of image along with the labels like an avatar, to make a form (boring by definition?) more lively. Do you really believe it was a mistake to make select fields accept a different label and value ? If not, then why don't the input+datalist do the same ?

And even then, what's the equivalent of a select multiple based on an input+datalist ? Please, forgive my ignorance, but I don't understand how to allow multiple selection with a datalist and an input and no JS, without having the user submit the form for each choice they want to add.

I to filter the datalist choices based on another field value without JS ? for example, a country field that would filter users.

How can I have a datalist of countries and a datalist of cities, so that you get to choose your city based on the country ? Do I have to omit the Country field and show 300k cities ? Do you realize how many cities are named "Springfield" ? The datalist would have to propose like 50 results at the time and the user would have to search through them (assuming their browser could load the 300k cities without crashing), wouldn't it be much better to first have a country and then state or region selector to make it easier for them ?

I'm not trying to create problems, I'm trying to find solution for problems that users actually have ... And I have a repo that does /just/ that with a very specific backend framework and has 1400+ stars so the problem seems pretty real to me ...

[chrismorgan]

I was never proposing datalist as a solution, far less a general one (it’s definitely not!), just pointing out its existence and potential suitability for some cases, and as a point of interest.

You can typically get a really long way with just plain text boxes, and then if they produce an invalid or probably-incorrect value, prompt them “did you mean such-and-such?” (and either force them to select a correct value or allow them to say “no, I really meant what I typed”). In fact this would sometimes be better than the types of combo boxes or autocompleting dropdowns people often use, which often have poorly-implemented failure flows (e.g. if you have to choose a valid value and it’s fetching valid values from the backend, and it makes you wait a second until the response comes back, ever time, or else it’ll forget you typed anything). And it can combine with live JS-powered validation if desired, or not.

Especially for addresses, I find the approach of allowing almost freeform text entry and then proposing ways of massaging it into shape to be excellent. Either one totally freeform field, or a series of text boxes depending on the country—and isn’t it an issue that we often put the country field last even when it can affect the understanding of earlier fields! But it’s technically more difficult to do this and requires extra functionality probably on the backend or via some external API to do well (to say nothing of countries with, shall we say, massage-resistant addresses), so software developers tend to do things the technically-trivial way rather than the more adventurous way that, if done well, will be better for users. (And perhaps it’s just as well, because if done badly it would be much worse.)

But really, most of what I’m talking about is just thinking about the no-JS behaviour, particularly when designing things from scratch. When you have an existing system that already doesn’t want to work that way you’re kinda stuck, but greenfield developments are a good time to lay down the right foundations.