Currently, the only ways to handle the diverse range of text input methods out there (IME composition, Emoji picker, handwriting recognition, etc.) are <input>, <textarea>, and contenteditable elements, which are not very customizable. Because of this, many text editors on the web resort to using a hidden editable element to handle text input and a canvas to render the text. This requires keeping the contents and position of the hidden element in sync with the canvas so that text input UI is rendered properly, which is cumbersome for developers, and can lead to webcompat bugs due to differences in text input between browsers. The EditContext API gives developers full control over the text input process, so that they can create custom editors with fewer difficulties and limitations.
EditContexts can be attached to either an ordinary DOM element (in which case the text rendering and selection are handled by the browser) or a <canvas> (in which case these are handled by the web developer). We plan to begin by only shipping the DOM-based EditContext, since there are more accessibility concerns with canvas-based EditContext (see discussion here).
See also: EditContext explainerBug: https://bugzilla.mozilla.org/show_bug.cgi?id=1904161
Specification: https://w3c.github.io/edit-context/
Standards Body: W3C
Platform Coverage: All
Preference: dom.editcontext.enabled
DevTools Bug: N/A
Extensions Bug: N/A
Use Counter: editcontext_constructor
Standards-Positions Discussion: https://github.com/mozilla/standards-positions/issues/199
Other Browsers:
Blink: Shipped in 121
WebKit: Considering (https://github.com/WebKit/standards-positions/issues/243)
web-platform-tests: https://github.com/web-platform-tests/wpt/tree/master/editing/edit-context