Hacker News Reader

You're also stuck with whatever you put in the option's value attribute - very unlike how a <select> works where the option has text content and a value.

Scenario: You've got customers, who have names and IDs. You want to search by name, but the ID needs to be sent to the server - you're right back to doing some JavaScript hack with a hidden field that gets a data-customerid attribute or whatever off of the selected option from a datalist.

View on HN

That actually sounds a lot like a <select>. If you need to have the customer ID, you won't be able to do much with just a customer name anyway. If you accept a name, you'd need to accept a separate ID too.

With select you have <option value="123">Customer Name</option> so the user sees Customer Name but submitting the form gets 123. With datalist you only have <option value="Customer Name"/> and the input tied to it gets Customer Name.

Yes. If you want to have the id, then why are you using a text input in the first place? This seems to be exactly the use case for a <select>.

For me, datalist is almost an acceptable compromise for a typical combobox (input + select/dropdown) control. Custom solutions for that require JS and are not accessible or otherwise don't behave as a user would expect a standard input to without lots of extra work.

It depends on the browser, but yes, it's a mess.

Reply on news.ycombinator.com