<datalist> is an underrated HTML API. It's basically a native autocomplete widget that requires 0 JavaScript. What I didn't know is how great it is on mobile devices. Especially the iOS Safari platform which is, to be honest, the only mobile device I have.

What's cool about it is that it's easy to implement, from a developer's point-of-view. But most importantly, it works great for users. The problem usually on mobile devices and autocomplete is that it's hard to find a good spot to display the suggestions. Most autocomplete widgets are a styled form of <div class="results"><ul><li>Suggestion 1</li><li>Suggestion 2</li></ul></div> that usually follows the <input> element. Usually, this simply boils down to screen height real estate. Oftentimes you want to display so much more rich stuff in the autocomplete results but it's hard to fit in a nice list of results between the <input> and the native keyboard display. For example, on this page ...

Lyrics search
Note how the search results get hidden underneath the keyboard.

Demo

The cool thing about <datalist> is that gets embedded in the native mobile keyboard in a sense. But what's extra cool is that the browser will do an OK job of filtering all the options for you, so that you, as a developer, just need to supply all options and the browser will take care of the rest.

I put together a dead-simple app here: https://cnfyl.csb.app/ (source here) which looks like this on iOS:

Sample search

Caveats

The space that the keyboard now populates with suggestions is usually reserved for helping you autocomplete regular words. It still does if you start typing a word that isn't an option. So arguably, the <datalist> options are primarily helping you when it's very likely that the user will type one of the suggestions.

The matching isn't great in my opinion. If you type "ea" it will match "Peaches" but I find it extremely unlikely that that's helping users. (What do you think?) If you've started typing "ea" if there's no match called "Each" or "North East" then it's probably better with no match at all.

Mind you, check out this hack (source here) which takes control of the <option> tags inside the <datalist> by having an event listener on the input. So if the input is "ea" it only matches expressions that are left-word-delimited and discard the rest.

Native filtering
Default/Native filtering

Custom filtering
Custom filtering

Conclusion

It is without a doubt the simplest autocomplete functionality you can buy. I would buy it again.

Perhaps it's not right for every application. Perhaps it's important to be able to include images in your autocomplete suggestions. Either way, the best thing to do is to park this in the back of your mind till next time you're up against the need for some sort of assisted search or choice. Especially if you predict you'll have a lot of users on mobile devices.

Comments

Your email will never ever be published.

Previous:
Test if two URLs are "equal" in JavaScript July 2, 2020 JavaScript
Next:
Lazy-load Firebase Firestore and Firebase Authentication in Preact September 2, 2020 Web development, Web Performance, Preact, JavaScript
Related by category:
Fastest way to find out if a file exists in S3 (with boto3) June 16, 2017 Web development
Be very careful with your add_header in Nginx! You might make your site insecure February 11, 2018 Web development
How to have default/initial values in a Django form that is bound and rendered January 10, 2020 Web development
Msgpack vs JSON (with gzip) December 19, 2017 Web development
Related by keyword:
First impressions of Meilisearch and how it compares to Elasticsearch January 26, 2023 Elasticsearch
Search GitHub issues by title, only May 31, 2024 GitHub
How to throttle AND debounce an autocomplete input in React March 1, 2018 Web development, React, JavaScript
How MDN's site-search works February 26, 2021 Python, Web development, Django, MDN, Elasticsearch