12 ms·

The <datalist> element tries to address a common use case: it provides an autocomplete-enabled input so that as the user types, they see a filtered list of vali

The <datalist> element tries to address a common use case: it provides an autocomplete-enabled input so that as the user types, they see a filtered list of valid options. It's great for prototyping, but its extensibility is so limited that it's not actually useful for real production applications. For example, you can't bold the parts of the options in the dropdown that match the input the user has entered in the text box. You can't add images or other rich content in the options. You can't style the dropdown itself. You can't do fuzzy matching. You can't receive events as the user keyboard-navigates through options... It's a shame, since it's not a bad start, but users expect more than what <datalist> provides, and so we always have to go with a custom solution.

tdy721 5y ago
It offers more than a bare input does. Why can’t I add Ajax for fuzzy matches? A custom drop down with keyboard events? Or I could hang all that off of an input. Or use a select? You’re saying stuff can’t be done. Out of the box sure? Why hate on it? This looks great to me.
- scrollaway 5y ago
  The more complex input elements can't always be styled, don't always have events available for things you'd expect etc. A bare input allows you to do those things from scratch, whereas a custom one is useless if you can't build on top of it. It's the curse of complex UI elements on the web. Menu failed for similar reasons.
  - beebeepka 5y ago
    Bending other people's higher level solutions to your needs
- enlyth 5y ago
  I'm not OP but I share his frustration with so many of the built in HTML elements. All of them seem like they're stuck in the 90s and just plain impossible to use for modern UI requirements. As someone who has worked on a lot of UI, one example of a common pattern I've ran into everywhere I've worked at is pic related: https://i.ibb.co/sgyzqYS/picrelated.png https://i.ibb.co/sgyzqYS/picrelated.png It usually has at least the following features: - Mutli-select that displays each item selected in the row - Chevron indicates selection - User can type in to search - Asynchronous loading/search from an API (because too many elements at once) - Custom styling to match whatever your design framework is Yeah no wonder why it's easier to just use React for everything.
  - menzoic 5y ago
    I think its a good thing that HTML doesn't bloat itself. It should offer the bare minimum for the ecosystem to build on. There's plenty of free options for extensible advanced UIs built by the open source community. If anything I also think browser vendors should make HTML element styles even more basic and the standard should allow for better custimozation and events instead of locking them down to a style that will get outdated.
  - tenaciousDaniel 5y ago
    My issue is that adding any functionality into native UI elements breaks the separation of concerns principle. You're wrapping structure, styling, and behavior all into one package, in a manner that is impossible to disentangle.
  - blacktriangle 5y ago
    Stuck in the 90s is generous. Win31 and MacOS both had built-in combo boxes with searching, styling, etc. Meanwhile the browser default multiple select UI is still one of the shittiest UI widgets ever built and its still all we have.
    - colejohnson66 5y ago
      Not only does it suck, it sucks to the point where some developers don’t use it for their forms (they use something better) and cause accessibility issues.
  - earthboundkid 5y ago
    I ended up shipping this as a similar autocomplete field: https://github.com/spotlightpa/almanack/blob/master/src/components/BulmaAutocompleteArray.vue https://github.com/spotlightpa/almanack/blob/master/src/comp... It's a little different because I put the chosen selections on a row above the input row, but the principle is the same.
arkitaip 5y ago
Autocomplete should have been part of HTML 20 years ago. It's incredibly frustrating how slow HTML moves when it comes to basic usability.
- Vinnl 5y ago
  Most painful is that the idea was [1] that the web would be extended with the ability to create your own custom elements so that we would no longer have to wait on web standards to evolve. In practice, it's still hardly practical to use those, yet "regular" HTML has hardly evolved either. [1] https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/
  - blowski 5y ago
    > so that we would no longer have to wait on web standards to evolve Isn't that exactly what we have today? I want a better <select> element, I drop in Select2. I want modals, I use Bootstrap modal. And so on. Particularly with libraries like React and Vue, where we literally type `<autocomplete options="..." />`.
    - Vinnl 5y ago
      I mean, sure, but we've always had that - but having widely-supported elements that are as good as the built-in elements with accessibility support and all, and have no dependencies and no requirements on a particular application architecture or framework use would certainly be nice.
      - blowski 5y ago
        I’m not sure I understand what you’re thinking of. If it’s native to one browser, then usage is restricted. To allow different browsers to use it means standards like we already have. JavaScript is the means by which websites can augment the browser with their own functionality - dependencies make it easier for developers to do this, but are not necessary. Plugins allow users to do the same. I can’t think how it could work differently.
cmg 5y ago
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.
- timw4mail 5y ago
  It depends on the browser, but yes, it's a mess.
- recursive 5y ago
  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.
  - cmg 5y ago
    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.
    - recursive 5y ago
      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>.
      - cmg 5y ago
        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.
beardyw 5y ago
The datalist could work well with the range input, if that itself wasn't a dog's breakfast.

tdy721 5y ago

It offers more than a bare input does. Why can’t I add Ajax for fuzzy matches? A custom drop down with keyboard events? Or I could hang all that off of an input. Or use a select? You’re saying stuff can’t be done. Out of the box sure? Why hate on it? This looks great to me.

scrollaway 5y ago
The more complex input elements can't always be styled, don't always have events available for things you'd expect etc. A bare input allows you to do those things from scratch, whereas a custom one is useless if you can't build on top of it. It's the curse of complex UI elements on the web. Menu failed for similar reasons.
- beebeepka 5y ago
  Bending other people's higher level solutions to your needs
enlyth 5y ago
I'm not OP but I share his frustration with so many of the built in HTML elements. All of them seem like they're stuck in the 90s and just plain impossible to use for modern UI requirements. As someone who has worked on a lot of UI, one example of a common pattern I've ran into everywhere I've worked at is pic related: https://i.ibb.co/sgyzqYS/picrelated.png https://i.ibb.co/sgyzqYS/picrelated.png It usually has at least the following features: - Mutli-select that displays each item selected in the row - Chevron indicates selection - User can type in to search - Asynchronous loading/search from an API (because too many elements at once) - Custom styling to match whatever your design framework is Yeah no wonder why it's easier to just use React for everything.
- menzoic 5y ago
  I think its a good thing that HTML doesn't bloat itself. It should offer the bare minimum for the ecosystem to build on. There's plenty of free options for extensible advanced UIs built by the open source community. If anything I also think browser vendors should make HTML element styles even more basic and the standard should allow for better custimozation and events instead of locking them down to a style that will get outdated.
- tenaciousDaniel 5y ago
  My issue is that adding any functionality into native UI elements breaks the separation of concerns principle. You're wrapping structure, styling, and behavior all into one package, in a manner that is impossible to disentangle.
- blacktriangle 5y ago
  Stuck in the 90s is generous. Win31 and MacOS both had built-in combo boxes with searching, styling, etc. Meanwhile the browser default multiple select UI is still one of the shittiest UI widgets ever built and its still all we have.
  - colejohnson66 5y ago
    Not only does it suck, it sucks to the point where some developers don’t use it for their forms (they use something better) and cause accessibility issues.
- earthboundkid 5y ago
  I ended up shipping this as a similar autocomplete field: https://github.com/spotlightpa/almanack/blob/master/src/components/BulmaAutocompleteArray.vue https://github.com/spotlightpa/almanack/blob/master/src/comp... It's a little different because I put the chosen selections on a row above the input row, but the principle is the same.

arkitaip 5y ago

Autocomplete should have been part of HTML 20 years ago. It's incredibly frustrating how slow HTML moves when it comes to basic usability.

Vinnl 5y ago
Most painful is that the idea was [1] that the web would be extended with the ability to create your own custom elements so that we would no longer have to wait on web standards to evolve. In practice, it's still hardly practical to use those, yet "regular" HTML has hardly evolved either. [1] https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/
- blowski 5y ago
  > so that we would no longer have to wait on web standards to evolve Isn't that exactly what we have today? I want a better <select> element, I drop in Select2. I want modals, I use Bootstrap modal. And so on. Particularly with libraries like React and Vue, where we literally type `<autocomplete options="..." />`.
  - Vinnl 5y ago
    I mean, sure, but we've always had that - but having widely-supported elements that are as good as the built-in elements with accessibility support and all, and have no dependencies and no requirements on a particular application architecture or framework use would certainly be nice.
    - blowski 5y ago
      I’m not sure I understand what you’re thinking of. If it’s native to one browser, then usage is restricted. To allow different browsers to use it means standards like we already have. JavaScript is the means by which websites can augment the browser with their own functionality - dependencies make it easier for developers to do this, but are not necessary. Plugins allow users to do the same. I can’t think how it could work differently.

cmg 5y ago

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.

timw4mail 5y ago
It depends on the browser, but yes, it's a mess.
recursive 5y ago
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.
- cmg 5y ago
  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.
  - recursive 5y ago
    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>.
    - cmg 5y ago
      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.

beardyw 5y ago

The datalist could work well with the range input, if that itself wasn't a dog's breakfast.