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.
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”:
|The user agent should present a cue for the operation ‘enter’, typically inserting a new line.|
|The user agent should present a cue for the operation ‘done’, typically meaning there is nothing more to input and the input method editor (IME) will be closed.|
|The user agent should present a cue for the operation ‘go’, typically meaning to take the user to the target of the text they typed.|
|The user agent should present a cue for the operation ‘next’, typically taking the user to the next field that will accept text.|
|The user agent should present a cue for the operation ‘previous’, typically taking the user to the previous field that will accept text.|
|The user agent should present a cue for the operation ‘search’, typically taking the user to the results of searching for the text they have typed.|
|The user agent should present a cue for the operation ‘send’, typically delivering the text to its target.|
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
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
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.
Do we also need to implement how the ‘next’ action jumps to the next input and how the ‘send’ action submits the form?
I think we do… I implemented sample functionality here in this CodePen: https://codepen.io/ericdjohnson/pen/QWqgyBW
This is also relevant for desktops because touchscreen laptops have on screen keyboards
Weird way to phrase that but I think I take your point. It would be interesting to link one of those up. Do you have one? A literal laptop computer that displays a virtual keyboard (instead of having a physical one entirely?)
If you have a laptop with a 360° hinge (convertible into a tablet), it should pop up a virtual keyboard when touching a text field. That said, support in practice can be spotty, with Windows 11 not supporting a dedicated touch mode anymore.
I would even say “changes the action key on a virtual keyboard (mobile, touch screens and accessibility options) to change the text/affordance.”
Because virtual keyboard are available on all windows devices under the accessibility setting panel if I recall well. But I suppose readers can understand it very well that way.
I’ve always used
<input type="search">to change the text of the enter-key to
"search"in mobile browsers on iOS.
(The same way that
<input type="email">affect the layout of soft / virtual keyboards)