To the extent that firing keydown before compositionstart is a problem for apps, that’s an issue that equally affects contenteditable. Changing the order may be a good improvement, but it will be a breaking change for the web that should be carefully considered and hopefully done in tandem with Firefox and Webkit so that browsers can arrive at matching behavior. I think tying EditContext to this is not necessary, as EditContext aims to solve a variety of problems around receiving text input aside from how keydown specifically is handled. Since EditContext does not make any changes around the order of keydown relative to other events, shipping EditContext should not add any additional complications to changing that event order if the Editing Working group decides to go that route.
The API is supported on Mac as well. If the sample you tried didn’t work it may be because we failed to update it in response to breaking changes. This sample is up-to-date and should serve to show simple text input and composition: https://magic-organic-yam.glitch.me/. Note that a lot of basic editing functionality isn’t implemented here, and the text formatting for compositions is with highlights rather than underlines -- this was built for testing the API, not real-world editing. As part of the Origin Trial, developers at Google Docs and Adobe included Mac in their testing and reported several Mac-specific issues that we’ve since fixed. If you’d like to try with the Docs implementation, let me know and I can ask about getting you opted in to that rollout. For reconversions, when a page is using EditContext the same UI will still be available to the user via the menu or hotkeys. The page keeps the platform informed about which text is selected by the user by calling EditContext.updateSelection()<https://w3c.github.io/edit-context/#dom-editcontext-updateselection>. When the user triggers a reconversion, Blink will send the page another TextUpdateEvent<https://w3c.github.io/edit-context/#dom-textupdateevent> indicating to it that it should change the text in the specified range to the new value. -- Dan From: Gregg Tavares <[email protected]> Sent: Tuesday, October 31, 2023 5:19 PM To: Daniel Clark <[email protected]> Cc: Gregg Tavares <[email protected]>; blink-dev <[email protected]>; Alex Keng <[email protected]>; Anupam Snigdha <[email protected]>; [email protected] Subject: Re: [blink-dev] Intent to Ship: EditContext API You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> I don't think the keydown issue should be ignored until after shipping this API. I think it's essential for this API to actually function. Consider an app that responds to Control-Shift-J for say "jump to definition". keydown = key = 'Control' keydown = key = 'Shift' (CtrlKey = true) keydown = key = 'K' (CtrlKey = true, Shift = true) And the app would trigger it's jump-to-definition command But what should have happened is the IME switched to Japanese mode (on Mac) and nothing happened in the app. It seems like this API is supposed to solve these issues but if keydown happens first then it seems like it fails at it's actual goal. The same issue but for different keys exists because of the difference in Firefox vs Chrome where in Chrome the app will mistakenly respond to keys it shouldn't and in Firefox it won't since Firefox hides those keys as 'Process'. Other questions: (*) Are we sure this API matches all platforms? It appears to be only implemented on Windows so far. The concern being, without implementing on other platforms before shipping, we may run into design issues that require changes to the API. I'm not remotely an expert in IME APIs but I know in my own domain, GPUs, if we didn't actually implement across APIs we'd have that issue. I wanted to test some things but I don't currently have access to a windows device and the sample didn't seem to work on my Mac with the EditContext API enabled. (*) How is recoversion handled in the canvas example? In a normal text editing area the user can select a portion of the text and pick "reconvert" either from menus or via hotkeys On Wed, Nov 1, 2023 at 8:09 AM Daniel Clark <[email protected]<mailto:[email protected]>> wrote: EditContext is not meant to be an interchangeable replacement for <input type=”text”>, contenteditable, etc, and most sites that want to receive simple text input will want to continue using the existing set of editing features. The target user of EditContext is one that has already reimplemented a lot of the editing stack, such that the browser’s built-in editing functionality is more of a hindrance than a help – the typical case here is something like Google Docs (where the entire editor view is reimplemented in a <canvas>). EditContext replaces hacks that sites like these often have to resort to such as hidden contenteditable elements that are floated around the page to position the IME window. A site that just wants to receive text input without building out their own fully-featured editing experience can and should continue using the existing “batteries-included” tools like <textarea> or contenteditable. The keydown event coming before compositionstart seems to be consistent with the existing contenteditable behavior in both Chromium and Firefox. While EditContext changes how some editing-related events are fired, some of the existing orderings like this were left in place for consistency’s sake when there wasn’t a strong reason to change them. The keydownevent.key interop difference is a good one to note, but I think it should be resolved orthogonally to EditContext. Since that behavior difference is present for both EditContext and contenteditable, the ideal outcome would be to bring this behavior in line across browsers for all editable fields. It looks like there are some stale issues in the EditingWG in that area, e.g. this one<https://github.com/w3c/uievents/issues/75> from before Gecko started firing keydown/keyup events during composition; maybe this should be taken back up by the WG to try to drive further interoperability in the area. If we end up making a change there it would apply both to EditContext and to other types of editable fields. -- Dan From: Gregg Tavares <[email protected]<mailto:[email protected]>> Sent: Monday, October 30, 2023 10:19 PM To: Daniel Clark <[email protected]<mailto:[email protected]>> Cc: blink-dev <[email protected]<mailto:[email protected]>>; Alex Keng <[email protected]<mailto:[email protected]>>; Anupam Snigdha <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [blink-dev] Intent to Ship: EditContext API You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Not a decider but one that sees the IME on many sites that try to roll their own text input. This sounds like a "if you do all of these 30 things perfectly, then maybe your site will work with most IME issues but you won't know unless you get someone experienced with IME users to test for you" solution Vs. some other solution which is "do nothing and it just works". The current "do nothing and it just works" is, use <input type="text"> or <textarea> or contenteditable. Is this API just giving developers lots of rope to hang themselves? Also, how does it align with other browsers? For example the explainer shows a sequence of events Event EventTarget key code event.text keydown focused element 'S' compositionstart active EditContext textupdate active EditContext 'S' textformatupdate active EditContext keyup focused element 'S' keydown focused element 'U' textupdate active EditContext 'す' textformatupdate active EditContext keyup focused element 'U' keydown focused element 'Space' textupdate active EditContext '巣' textformatupdate active EditContext compositionend active EditContext keyup focused element 'Space' That seems non-intuitive to me. I get a keydown first, at which point my app reacts when it wasn't supposed to as the key was meant for the IME. Also, this table doesn't seem to match Firefox for example, pressing 's' when in Japanese input mode pops up the IME and in firefox it produces event.key = 'Process', not event.key = 's' which at least makes more sense since the input should be going to the IME, not the page. On Tue, Oct 31, 2023 at 2:52 AM 'Daniel Clark' via blink-dev <[email protected]<mailto:[email protected]>> wrote: Contact emails [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> 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 IME Compositions and speech recognition, 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 Completed (Resolution: satisifed) at https://github.com/w3ctag/design-reviews/issues/416 TAG review status Issues addressed Chromium Trial Name EditContext Link to origin trial feedback summary https://github.com/w3c/edit-context/ Origin Trial documentation link https://github.com/w3c/edit-context/blob/gh-pages/explainer.md In the Origin Trial the Google Docs team used EditContext to receive IME input and position the IME window for Docs, replacing the current approach of manually positioning a hidden contenteditable element over the document when composing text. The new EditContext approach is more performant and supports a wider range of IME interactions. We received similar feedback from Adobe, who are also using EditContext to replace a hidden text input element for triggering the IME. Risks Interoperability and Compatibility There are no known interop or compat risks. Gecko: Under consideration (https://github.com/mozilla/standards-positions/issues/199) WebKit: No signal (https://github.com/WebKit/standards-positions/issues/243) Web developers: Strongly positive Positive feedback from Word online, Adobe and Figma, Google Docs Other signals: Ergonomics None. 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. Security No particular security risks. See https://github.com/w3c/edit-context/blob/gh-pages/security-privacy.md. 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? None. Debuggability Existing DevTools features should be sufficient for debugging EditContext. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes. This is a core web platform feature that is not limited to any particular underlying platform. Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? Yes. Tests are available at https://wpt.fyi/results/editing/edit-context?label=experimental&label=master&aligned Note that some composition scenarios are not yet testable in WPT due to a dependency on content_shell-only test APIs. Work is underway to add functionality for mocking IME input in WPTs such that these tests can be moved to WPT. Flag name on chrome://flags edit-context Finch feature name EditContext Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=999184 Measurement The UseCounter WebFeature::kEditContext tracks instantiation of EditContext. Availability expectation We expect other browser vendors to be interested in implementing this feature, though we cannot comment on specific timelines. Adoption expectation Feature will be used by Google Docs upon launch in Chrome. Adoption plan We are already working with the Docs team as a partner in the feature's Origin Trial, where they have implemented composition using EditContext. Non-OSS dependencies Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function? None. Estimated milestones Shipping on desktop 121 OriginTrial desktop last 120 OriginTrial desktop first 116 OriginTrial Android last 120 OriginTrial Android first 116 OriginTrial webView last 120 OriginTrial webView first 116 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). Open spec issues can be found here: https://github.com/w3c/edit-context/issues We expect these issues to be resolved in a forward-compatible way and/or to only affect rare corner-cases. Many of these discuss potential additions to the feature that will be considered based on ongoing developer feedback as EditContext is adopted more widely. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5041440373604352 Links to previous Intent discussions Intent to Implement: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/QZQrESwcK3o/m/k3pfYBcRBAAJ -- 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1654118011BA087BA5058967C5A1A%40MW4PR00MB1654.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1654118011BA087BA5058967C5A1A%40MW4PR00MB1654.namprd00.prod.outlook.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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH7PR00MB1637386167B3A830D5D06D0AC5A7A%40PH7PR00MB1637.namprd00.prod.outlook.com.
