Blog

I only just recently learned the enterkeyhint attribute on form inputs was a thing! It seems like kind of a big deal to me, as crafting HTML form markup is a decent slice of a front-end developer’s life, and this attribute could (should?) be used on nearly every input.

The enterkeyhint attribute changes the action key on a mobile keyboard to change the text/affordance. Stefan Judis spells it out nicely in this tweet from 2020:

So, say I have a form like this:

<form> <label> Name: <input type="text" name="name"> </label> <label> Favorite songs: <textarea name="songs"></textarea> </label> <button>Save</button>
</form>

The user experience there suggests form that “Saves” but by default on the iPhone in my hand, the blue button in the keyboard says… “go.”

That’s not a disaster or anything, but now I’ve got some options for that button. I’ll steal this from the spec, which refers to them as “input modalities”:

As a serious web professional, I also tried enterkeykint="poop" but, alas, it was not respected by the browser. Note that on Android the action button doesn’t just always turn into text, but uses icons. So for the value send, you get a little paper airplane icon rather than the “send” label. So, yeah, obviously poop should have turned into 💩.

For the little form example above… the value enter or done somehow feels better to me than go. If I want to change that, I’d add the attribute for all interactive form elements:

<form> <label> Name: <input type="text" name="name" enterkeyhint="done"> </label> <label> Favorite songs: <textarea name="songs" enterkeyhint="done"></textarea> </label> <button enterkeyhint="done">Save</button>
</form>

This attribute goes directly on the form inputs, so it feels a bit repetitive writing it for each and every input, especially in longer forms. But it does give you an opportunity to change it depending on what input is focused.

I notice that save isn’t a valid option. That seems weird as it feels like what a lot of forms would offer. Perhaps the web platform doesn’t want to offer something that tells users something they can’t possibly enforce? I’m not sure that’s the case, though, because if you put in next or previous that doesn’t change the behavior at all—you’d have to code that yourself if what you want to do is move focus to the next or previous inputs. By default, the action button just submits the form as it normally would.

I came across all this as Stefan more recently tweeted that Firefox is supporting it now, offering a largely complete set of support for this feature. This feature is only relevant to mobile browsers (or, I suppose, browsers that support virtual keyboards?) so it had me thinking about that Firefox Mobile exists. I’m so used to the fact that all browsers are Safari on iOS (🤬). But on Android, you can use “real” Firefox, which is a good reminder that not only do different mobile browsers exist, but different mobile browsers have different behavior as well.

In this video, which I’m sure predates support for enterkeyhint, note how the virtual keyboard offers UI for next automatically when focused on the first input (and no way to submit directly), but on the second (and last) the action, the button turns into a submit button (and there is no “previous” button). This is markedly different from iOS where all that’s offered is navigation between inputs with little up and down arrows that sit above the keyboard itself.

All in all, a pretty cool feature that we should all at least be aware of if not use on most HTML forms we create to match the behaviors.

The post enterkeyhint appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.