Contact emails sni...@microsoft.com<mailto:sni...@microsoft.com>, shih...@microsoft.com<mailto:shih...@microsoft.com>, bemat...@microsoft.com<mailto:bemat...@microsoft.com>, dan...@microsoft.com<mailto:dan...@microsoft.com>
Explainer https://github.com/w3c/edit-context/blob/gh-pages/explainer.md Specification https://w3c.github.io/edit-context Design docs https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md Summary The EditContext API simplifies the process of integrating a web app with advanced text input methods such as VK shape-writing, Handwriting panels, speech recognition, IME Compositions etc., improves accessibility and performance, and unlocks new capabilities for web-based editors. Blink component Blink>Editing<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EEditing> Search tags editing<https://chromestatus.com/features#tags:editing>, contenteditable<https://chromestatus.com/features#tags:contenteditable>, input<https://chromestatus.com/features#tags:input>, rawinput<https://chromestatus.com/features#tags:rawinput>, ime<https://chromestatus.com/features#tags:ime> TAG review https://github.com/w3ctag/design-reviews/issues/416 TAG review status Pending Risks Interoperability and Compatibility There are no known interop or compat risks. Gecko: No signal WebKit: No signal Web developers: Strongly positive Positive feedback from Word online, Adobe and Figma, Google Docs Other signals: Activation Developers interested in this feature will typically have their own polyfill for text input using hidden textarea or contenteditable elements. Feature detecting and using new API to avoid side effects of previous approaches is intended to be easily adoptable. WebView application risks None Goals for experimentation We are looking for feedback on the developer ergonomics of using the API and for confirmation that it meets the needs of production web apps for various input modes. This is a complex API, and different developers are expected to use it in different ways. For example, some partners plan to construct the view of their editable region in the subtree of the EditContext-associated element, while other partners plan to keep the EditContext-associated element off-screen while using the EditContext APIs to set the bounds of the editable region. We want to ensure that our design enables all these scenarios and is robust given the wide field of IMEs utilized by different users, which may have subtly different behaviors and event timings. Ongoing technical constraints None Debuggability Existing DevTools functionality should suffice to debug EditContext. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? No Flag name --enable-blink-features=EditContext Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=999184 Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5041440373604352 Links to previous Intent discussions I2I: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0448C960D827BFAFE2FD1F2CC554A%40SN6PR00MB0448.namprd00.prod.outlook.com.
