The autocorrect attribute: giving the page a say in auto-correction
Chrome 152 supports the global autocorrect attribute, Safari and Firefox had it already, and so it reaches Baseline. How it differs from spellcheck, why it spent years as a vendor prefix, and when you should turn it off.
Chrome 152 added support for the global autocorrect attribute and reflects it on HTMLElement.prototype.autocorrect. Safari and Firefox already had it, so the attribute reaches Baseline Newly available.
Its scope is editable elements: <input>, <textarea>, and anything with contenteditable. It takes two values: on and off.
It is not the same as spellcheck
The two are often treated as one thing, but they govern different behaviour:
| Governs | |
|---|---|
spellcheck |
whether to draw a red squiggle |
autocorrect |
whether to replace what you typed |
A squiggle is a hint; ignore it and nothing happens. Auto-correction changes your text. Entirely different severity.
So “spellcheck off, autocorrect on” is a sensible combination: I do not want underlines, but I do not mind my phone turning teh into the.
Why it was vendor-prefixed for years
Before standardisation, the incantation was:
<input autocorrect="off" autocapitalize="off" autocomplete="off" spellcheck="false">There, autocorrect is a Safari-only attribute; Chrome and Firefox ignore it. So one intention required three or four different switches, plus a hope that they would not fight each other.
That is the value of standardising it: one intention, one attribute, all three engines.
When to turn it off
Auto-correction is helpful for natural language and disastrous for:
Code, identifiers, paths
When the field holds my_var_name, user.id, or /api/v1/token, auto-correction “fixes” them into natural-language words — and you may not notice, because it changes case, hyphens, or quietly inserts a space.
<input name="identifier" autocorrect="off" autocapitalize="off" spellcheck="false">Usernames, email addresses, URLs
Same reasoning. Auto-capitalisation in an email field is especially nasty: User@Example.com is a different string from user@example.com to some backends.
One-time codes and keys
Those fields usually have a fixed character set, and auto-correction only introduces surprises.
When to leave it on
- Search boxes
- Comments and replies
- Long-form editors
- Anywhere you would want help while typing on a phone
Where I land
There is no technical depth here — it unifies a switch that every engine already had. But it is a good illustration that the browser changing what the user typed needs explicit permission.
The old arrangement was “help by default, and if you object, add a pile of vendor attributes”. The new one is “help by default, with one standard switch all three engines honour”. That is the right direction: a feature that makes decisions on the user’s behalf should come with a cheap way out.
One more thing: reflecting HTMLElement.prototype.autocorrect means JavaScript can read it too. Useful for small touches like adapting hint copy to the current setting — but do not use it to guess what the user is thinking.
Comments
…