Build a Better Mobile Input
This is such a handy tool for building forms! Choose different combinations of type
, inputmode
, and autocomplete
attributes on input
elements and see how that will be conveyed to users on iOS and Android devices.
This is such a handy tool for building forms! Choose different combinations of type
, inputmode
, and autocomplete
attributes on input
elements and see how that will be conveyed to users on iOS and Android devices.
I’m a big fan of HTML5’s datalist
element and its elegant design. It’s a way to progressively enhance any input
element into a combobox.
You use the list
attribute on the input
element to point to the ID of the associated datalist
element.
<label for="homeworld">Your home planet</label>
<input type="text" name="homeworld" id="homeworld" list="planets">
<datalist id="planets">
<option value="Mercury">
<option value="Venus">
<option value="Earth">
<option value="Mars">
<option value="Jupiter">
<option value="Saturn">
<option value="Uranus">
<option value="Neptune">
</datalist>
It even works on input type="color"
, which is pretty cool!
The most common use case is as an autocomplete widget. That’s how I’m using it over on The Session, where the datalist
is updated via Ajax every time the input is updated.
But let’s stick with a simple example, like the list of planets above. Suppose the user types “jup” …the datalist will show “Jupiter” as an option. The user can click on that option to automatically complete their input.
It would be handy if you could automatically submit the form when the user chooses a datalist option like this.
Well, tough luck.
The datalist
element emits no events. There’s no way of telling if it has been clicked. This is something I’ve been trying to find a workaround for.
I got my hopes up when I read Amber’s excellent article about document.activeElement
. But no, the focus stays on the input when the user clicks on an option in a datalist.
So if I can’t detect whether a datalist has been used, this best I can do is try to infer it. I know it’s not exactly the same thing, and it won’t be as reliable as true detection, but here’s my logic:
Here’s how that translates into DOM scripting code:
document.querySelectorAll('input[list]').forEach( function (formfield) {
var datalist = document.getElementById(formfield.getAttribute('list'));
var lastlength = formfield.value.length;
var checkInputValue = function (inputValue) {
if (inputValue.length - lastlength > 1) {
datalist.querySelectorAll('option').forEach( function (item) {
if (item.value === inputValue) {
formfield.form.submit();
}
});
}
lastlength = inputValue.length;
};
formfield.addEventListener('input', function () {
checkInputValue(this.value);
}, false);
});
I’ve made a gist with some added feature detection and mustard-cutting at the start. You should be able to drop it into just about any page that’s using datalist. It works even if the options in the datalist are dynamically updated, like the example on The Session.
It’s not foolproof. The inference relies on the difference between what was previously typed and what’s autocompleted to be more than one character. So in the planets example, if someone has type “Jupite” and then they choose “Jupiter” from the datalist, the form won’t automatically submit.
But still, I reckon it covers most common use cases. And like the datalist
element itself, you can consider this functionality a progressive enhancement.
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct
type
,inputmode
, andautocomplete
attributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
This is an excellent deep dive with great advice:
You may think that you are familiar with the basic
autocomplete
options, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!
The many ways of improving a single form field in HTML.
I love these kinds of deep dives into markup!
When I liveblogged Jason’s talk at An Event Apart in Chicago, I included this bit of reporting:
Jason proceeds to relate a long and involved story about buying burritos online from Chipotle.
Well, here is that story. It’s a good one, with some practical takeaways (if you’ll pardon the pun):
- Use HTML5 input features
- Support autofill
- Make autofill part of your test plans
If you’re looking for an accessible standalone autocomplete script, this one from GDS looks very good (similar to Lea’s awesomplete).
This is a really good use-case for cancelling fetch requests: making API calls while autocompleting in search.
A few straightforward steps for improving the usability of credit card forms. The later steps involve JavaScript but the first step uses nothing more than straight-up HTML.
Equal parts clever and scary. By using autocomplete
in HTML and some offscreen positioning in CSS, it’s possible to extract some unexpected personal information.
I expect browsers will be closing these holes pretty quickly.
Jason takes good look at the browser support for autocomplete values and then makes a valiant attempt to make up for the complete lack of documentation for Safari’s credit card scanning.
A useful primer on which combinations of attributes and values work best for which form fields: type
, autocomplete
, autocorrect
, and autocapitalize
.
Lea wasn’t happy with the lack of styling and extensibility of the datalist element, so she rolled her own lightweight autocomplete/type-ahead widget, and she’s sharing it with the world.
The accidental beauty in Google’s autosuggest algorithm.
Yeah, it’s an April Fool’s video (lamest day on the internet) but this is amusing.