Intent to Prototype: EditContext

75 views
Skip to first unread message

Leo Tenenbaum

unread,
May 12, 2026, 9:30:47 AM (5 days ago) May 12
to dev-pl...@mozilla.org

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 explainer 

Bug: 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:

web-platform-tests:   https://github.com/web-platform-tests/wpt/tree/master/editing/edit-context

Reply all
Reply to author
Forward
0 new messages