On Sat, Mar 14, 2026 at 3:03 AM Chromestatus < [email protected]> wrote:
> *Contact emails* > [email protected] > > *Specification* > https://html.spec.whatwg.org/multipage/interaction.html#autocorrection > > *Summary* > The HTML autocorrect attribute allows web authors to control whether > autocorrection should be applied to user input in editable elements > including <input>, <textarea>, and contenteditable hosts. On Windows, the > touch keyboard ignores this attribute and always autocorrects words. For > example, typing "truf" followed by space in an element with > autocorrect="off" yields "true " instead of preserving "truf ". This > feature makes Chrome's TSF integration detect and revert touch keyboard > autocorrections when the focused editable element has autocorrect="off" set. Just curious -- TSF here means text services framework? It's basically an IME framework? Christian > > > *Blink component* > Blink>Editing>IME > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EEditing%3EIME%22> > > *Web Feature ID* > autocorrect <https://webstatus.dev/features/autocorrect> > > *Motivation* > The autocorrect attribute is defined in the HTML Living Standard and > applies to both form controls (<input>, <textarea>) and editing hosts > (elements with contenteditable). On Android, Chrome correctly communicates > this preference to the soft keyboard via EditorInfo.inputType flags. On > Windows, however, TSF's InputScope interface has no autocorrect field, so > the touch keyboard is unaware of the page's preference and always > autocorrects. This creates a broken experience for web apps that explicitly > disable autocorrection such as code editors, username/email fields, medical > or legal forms, and any scenario where precise user input must be > preserved. This feature fixes the gap by having Chrome detect and revert > touch keyboard autocorrections at the TSF layer when autocorrect="off" is > set on the focused editable element. Moreover, Autocorrect is performed > only by the touch keyboard's prediction engine. Physical keyboards and > traditional IMEs go through composition ranges and are unaffected. Firefox > also does not honor autocorrect="off" on the Windows touch keyboard, > verified that it autocorrects every time. For non-touch (physical > keyboard), neither browser has autocorrected behavior. > > *Initial public proposal* > *No information provided* > > *TAG review* > Not Applicable > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: No signal ( > https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocorrect > ) > > *WebKit*: No signal (https://bugs.webkit.org/show_bug.cgi?id=289197) > > *Web developers*: No signals > > *Other signals*: > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > No. This change is Windows-only. It has no impact on Android, Android > WebView, or any non-Windows platform. A kill switch > (kTSFHonorAutocorrectOff) is in place regardless. > > > *Debuggability* > No DevTools changes needed. This feature operates entirely at the OS input > layer (TSF) and does not introduce new web-facing APIs, events, or state. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > No > Already supported on Android. This change specifically adds support for > windows TKB. > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > Adding WPT not feasible for this change. Unit tests have been added for > automated testing for the feature. A manual WPT has been created for the > change. Link - > https://wpt.live/html/editing/editing-0/autocorrection/autocorrect-off-touch-keyboard-manual.html > > *Flag name on about://flags* > Not Applicable > > *Finch feature name* > kTSFHonorAutocorrectOff > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/487613498 > > *Estimated milestones* > Shipping on desktop 148 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > No > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5196629995028480?gate=6520647549321216 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b50845.050a0220.87ff1.0cb0.GAE%40google.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b50845.050a0220.87ff1.0cb0.GAE%40google.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XGLVNzDFU2kM%3DzrN95wESwQXuu0M3uLqt4TJfijDsJFiA%40mail.gmail.com.
