I solely only in the near past realized the enterkeyhint attribute on type inputs was a factor! It looks as if sort of an enormous deal to me, as crafting HTML type markup is a good slice of a front-end developer’s life, and this attribute may (ought to?) be used on practically each enter.

The enterkeyhint attribute modifications the motion key on a cell keyboard to vary the textual content/affordance. Stefan Judis spells it out properly on this tweet from 2020:

So, say I’ve a type like this:

<type>
  <label>
    Title:
    <enter kind="textual content" title="title">
  </label>
  <label>
    Favourite songs:
    <textarea title="songs"></textarea>
  </label>
  <button>Save</button>
</type>

The consumer expertise there suggests type that “Saves” however by default on the iPhone in my hand, the blue button within the keyboard says… “go.”

iPhone screenshot of a simple form on a plain webpage and the phone's touch keyboard displayed. The primary button where the Enter key normally is located is replaced by go.
The default motion button on the cell keyboard of iOS is “go”

That’s not a catastrophe or something, however now I’ve obtained some choices for that button. I’ll steal this from the spec, which refers to them as “enter modalities”:

Key phraseDescription
enterThe consumer agent ought to current a cue for the operation ‘enter’, sometimes inserting a brand new line.
completedThe consumer agent ought to current a cue for the operation ‘completed’, sometimes that means there’s nothing extra to enter and the enter technique editor (IME) might be closed.
goThe consumer agent ought to current a cue for the operation ‘go’, sometimes that means to take the consumer to the goal of the textual content they typed.
subsequentThe consumer agent ought to current a cue for the operation ‘subsequent’, sometimes taking the consumer to the following subject that can settle for textual content.
earlierThe consumer agent ought to current a cue for the operation ‘earlier’, sometimes taking the consumer to the earlier subject that can settle for textual content.
searchThe consumer agent ought to current a cue for the operation ‘search’, sometimes taking the consumer to the outcomes of looking for the textual content they’ve typed.
shipThe consumer agent ought to current a cue for the operation ‘ship’, sometimes delivering the textual content to its goal.

As a critical net skilled, I additionally tried enterkeykint="poop" however, alas, it was not revered by the browser. Observe that on Android the motion button doesn’t simply at all times flip into textual content, however makes use of icons. So for the worth ship, you get a bit of paper airplane icon slightly than the “ship” label. So, yeah, clearly poop ought to have became 💩.

For the little type instance above… the worth enter or completed in some way feels higher to me than go. If I need to change that, I’d add the attribute for all interactive type components:

<type>
  <label>
    Title:
    <enter kind="textual content" title="title" enterkeyhint="completed">
  </label>
  <label>
    Favourite songs:
    <textarea title="songs" enterkeyhint="completed"></textarea>
  </label>
  <button enterkeyhint="completed">Save</button>
</type>

This attribute goes immediately on the shape inputs, so it feels a bit repetitive writing it for every enter, particularly in longer varieties. But it surely does give you a chance to vary it relying on what enter is concentrated.

I discover that save isn’t a legitimate possibility. That appears bizarre because it appears like what plenty of varieties would supply. Maybe the online platform doesn’t need to supply one thing that tells customers one thing they’ll’t presumably implement? I’m undecided that’s the case, although, as a result of if you happen to put in subsequent or earlier that doesn’t change the habits in any respect—you’d need to code that your self if what you need to do is transfer focus to the following or earlier inputs. By default, the motion button simply submits the shape because it usually would.

I got here throughout all this as Stefan extra lately tweeted that Firefox is supporting it now, providing a largely full set of help for this characteristic. This characteristic is just related to cell browsers (or, I suppose, browsers that help digital keyboards?) so it had me eager about that Firefox Cellular exists. I’m so used to the truth that all browsers are Safari on iOS (🤬). However on Android, you should utilize “actual” Firefox, which is an effective reminder that not solely do completely different cell browsers exist, however completely different cell browsers have completely different habits as properly.

On this video, which I’m positive predates help for enterkeyhint, observe how the digital keyboard provides UI for subsequent robotically when centered on the primary enter (and no technique to submit immediately), however on the second (and final) the motion, the button turns right into a submit button (and there’s no “earlier” button). That is markedly completely different from iOS the place all that’s supplied is navigation between inputs with little up and down arrows that sit above the keyboard itself.

All in all, a reasonably cool characteristic that we must always all at the very least pay attention to if not use on most HTML varieties we create to match the behaviors.

#enterkeyhint #CSSTricks

Leave a Reply

Your email address will not be published. Required fields are marked *