Intent to Experiment: EditContext API

413 views
Skip to first unread message

Daniel Clark

unread,
Jun 12, 2023, 7:13:19 PM6/12/23
to blin...@chromium.org, Chris Harrelson, Anupam Snigdha, Alex Keng

Contact emails

sni...@microsoft.com, shi...@microsoft.com, bema...@microsoft.com, 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


Search tags

editing, contenteditable, input, rawinput, 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?

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.

 

Joshua Bell

unread,
Jun 12, 2023, 7:44:51 PM6/12/23
to Daniel Clark, blin...@chromium.org, Chris Harrelson, Anupam Snigdha, Alex Keng
I'm excited to see this!

Although in the template this is phrased as a yes/no question, can you say more about the WPT coverage and limitations?
 


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.

 

--
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+...@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.

Mike Taylor

unread,
Jun 13, 2023, 12:23:49 PM6/13/23
to Daniel Clark, blin...@chromium.org, Chris Harrelson, Anupam Snigdha, Alex Keng

Do you all have a timeline in mind for experimentation?

--

Daniel Clark

unread,
Jun 13, 2023, 1:42:20 PM6/13/23
to Mike Taylor, blin...@chromium.org, Chris Harrelson, Anupam Snigdha, Alex Keng

Tentatively M116 - M120 for the trial.

Daniel Clark

unread,
Jun 13, 2023, 6:03:30 PM6/13/23
to Mike Taylor, blin...@chromium.org, Joshua Bell, Chris Harrelson, Anupam Snigdha, Alex Keng

> Although in the template this is phrased as a yes/no question, can you say more about the WPT coverage and limitations?

 

We currently do not have tests in web-platform-tests.

There are tests outside the external/wpt folder:

third_party/blink/web_tests/editing/input/edit-context.html

third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html

 

I’m going to migrate as much of the contents of these as I can to WPT. This won’t be possible for a lot of the subtests since they rely on primitives like eventSender and textInputController, which aren’t available in WPT.

There is also test coverage that still needs to be written for scenarios involving nested editable elements, and I plan to add these as WPTs.

 

There’s been some work done around adding support for IME testing but my understanding is that more work is needed in order to use this in WPTs.

Brian Birtles

unread,
Jun 13, 2023, 10:10:30 PM6/13/23
to blink-dev, dan...@microsoft.com, chri...@google.com, snianu, Alex Keng
As a Web developer, I'm very happy to see this. Thank you!

I notice that it introduces new editing events, however. It would be amazing if we could first get the ordering of the existing set of edit/compose events to be interoperable.

For example, the following issue has stalled, waiting on Blink input: https://github.com/w3c/uievents/issues/202

While this spec would be wonderful, I suspect fixing the existing events would have an even greater impact, and it would be certainly nice to do that before further complicating the picture.

Thank you again,

Brian

2023年6月13日火曜日 8:13:19 UTC+9 dan...@microsoft.com:

Yoav Weiss

unread,
Jun 14, 2023, 12:02:34 AM6/14/23
to Daniel Clark, Mathias Bynens, Mike Taylor, blin...@chromium.org, Joshua Bell, Chris Harrelson, Anupam Snigdha, Alex Keng
On Wed, Jun 14, 2023 at 12:03 AM 'Daniel Clark' via blink-dev <blin...@chromium.org> wrote:

> Although in the template this is phrased as a yes/no question, can you say more about the WPT coverage and limitations?

 

We currently do not have tests in web-platform-tests.

There are tests outside the external/wpt folder:

third_party/blink/web_tests/editing/input/edit-context.html

third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html

 

I’m going to migrate as much of the contents of these as I can to WPT. This won’t be possible for a lot of the subtests since they rely on primitives like eventSender and textInputController, which aren’t available in WPT.

There is also test coverage that still needs to be written for scenarios involving nested editable elements, and I plan to add these as WPTs.


Would it be possible to add WebDriver extensions to enable these tests to move over to WPT?

It'd be good to file for positions (even if that doesn't block an OT)
 


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.


Do we plan for each property that adopts this to write their own polyfill? Or to split their code paths for supporting and non supporting browsers? 

Alex Russell

unread,
Jun 14, 2023, 11:31:51 AM6/14/23
to blink-dev, Yoav Weiss, Mike Taylor, blin...@chromium.org, Joshua Bell, chri...@google.com, snianu, Alex Keng, dan...@microsoft.com, mt...@google.com
LGTM to experiment assuming WPT caveats are addressed.

On editing event order, perhaps we can track this separately. Is there a crbug for it?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.


To view this discussion on the web visit

--
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+unsubscribe@chromium.org.

Daniel Clark

unread,
Jun 15, 2023, 7:31:59 PM6/15/23
to Alex Russell, blink-dev, Yoav Weiss, Mike Taylor, blin...@chromium.org, Joshua Bell, chri...@google.com, Anupam Snigdha, Alex Keng, mt...@google.com

Thanks Alex!

 

It looks like crbug.com/1263817 is a good tracking bug for https://github.com/w3c/uievents/issues/202 (which is already linked from there). Since EditContext differs in how these events will fire I think this issue can be resolved separately, but I’ve tagged some folks in on that issue to try to drive some progress.

 

I’ll investigate what can be done to get the tests moved to WPT.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

Nicola Tommasi

unread,
Jun 27, 2023, 4:02:45 AM6/27/23
to blink-dev, dan...@microsoft.com, Yoav Weiss, Mike Taylor, blin...@chromium.org, Joshua Bell, chri...@google.com, snianu, Alex Keng, mt...@google.com, Alex Russell, Arthur Sonzogni
Hi, from a privacy perspective we have some concerns regarding the spellchecker section: we enforced in the past the concept that websites should not learn about the user dictionaries [1] and it seems like the spellcheking API proposal could leak those via the textformatupdate event. Was this taken into consideration?Do we have any way to prevent this?


Thanks,
Nicola

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Daniel Clark

unread,
Jun 27, 2023, 6:47:30 PM6/27/23
to Nicola Tommasi, blink-dev, Yoav Weiss, Mike Taylor, blin...@chromium.org, Joshua Bell, chri...@google.com, Anupam Snigdha, Alex Keng, mt...@google.com, Alex Russell, Arthur Sonzogni

Hi Nicola,

The textformatupdate event does not get fired in response to browser spell checking. It's only used for decorations applied by IMEs to give hints to users during composition, e.g. thin/thick underlines for "phrase mode" in Japanese IME.

Spell checking for an EditContext depends on how the author builds the view of their Editor.

If the author builds with "normal" DOM elements -- <div>, <span>, etc -- the platform will run the spell-checker on these like any other editable elements, drawing the underlines and allowing the user to choose corrections. EditContext will not see any of this, and will only be able to tell at the point that the user has chosen a suggestion, e.g. by listening for beforeinput with event.inputType === "insertReplacementText". So spell-checking will work much like a normal contenteditable div today.

If the author uses <canvas>, the platform's native spellcheck will have no way to integrate with the EditContext. By using <canvas>, the author is taking on the responsibility for building out their editor from scratch, including spell-checking if needed by their application.

-- Dan

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

Reply all
Reply to author
Forward
0 new messages