EditContext

[BoCupp-Microsoft]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: EditContext
• Explainer: https://github.com/w3c/edit-context/blob/gh-pages/explainer.md
• Specification: https://w3c.github.io/edit-context/
• Mozillians who can provide input (optional): @masayuki-nakano

Other information

This is an API to enable the text input services of the OS (IME support, emoji picking, handwriting recognition panel, etc) without needing an editable element in the DOM to be focused. Without something like this API, sites like Word Online, Google Docs and the Monaco editor need to scrape their input out of an editable element - the code is complex and has a negative impact on accessibility. We are working with them on this proposal and they have expressed interest in it. Please see the explainer for details.

Thanks in advance for your thoughts!

[masayuki-nakano]

Sorry for the delay to reply. I'm still reading the proposal and thinking concerns of it when I have much time.

[marcoscaceres]

Removed WICG label, as this is not yet a WICG adopted spec.

[smaug----]

This was discussed during TPAC
https://lists.w3.org/Archives/Public/public-editing-tf/2019Oct/0004.html

The idea to have a way to deal with text input without DOM sounds good to me, but the proposal feels still rather rough idea and it hasn't been updated based on the feedback at TPAC.

[annevk]

My worry is that we haven't seen much progress on the interoperability issues with existing editing primitives. So to then add a new set of issues is not a particularly appealing proposition.

[BoCupp-Microsoft]

@annevk We're making progress with an actual implementation and sample applications and are finding and resolving issues. We will update the documents based on our progress.

If you have specific interoperability issues with existing editing primitives beyond those we've enumerated in the explainer, please be sure to call those out so we don't miss anything you're worried about.

Thanks!
Bo

[alexkeng]

Hi we have updated spec draft and explainer for EditContext. Could you help reevaluate the feature and provide Mozilla's position? Thanks!

Here is the latest spec draft:
https://w3c.github.io/editing/docs/EditContext/index.html

her is the explainer (the API surface is little outdated compared to the spec draft, but there is more introductory info):
https://github.com/alexkeng/editing/blob/gh-pages/docs/EditContext/explainer.md

[annevk]

To give an update here, evaluation is on hold pending an update to the specification. w3c/edit-context#23 is the most significant issue we've raised I think, but there are a couple of others too.

[dandclark]

We've made a number of changes that address the feedback raised in w3c/edit-context#23 and the sub-issues linked from there. Individual changes can be seen at https://github.com/w3c/edit-context/commits/gh-pages but some of these are broad-sweeping and overlapping so it's probably simplest to just take another pass through the spec.

The spec has also moved since this Issue was last active: the new link is https://w3c.github.io/edit-context/

Mozilla reviewers, could you please take another look?

[masayuki-nakano]

Thank you. I'm starting to check the latest draft.

[marijnh]

This issue has been quiet for a while now. I see there is now an issue on the Mozilla bug tracker labeled "Implement EditContext", but that was opened by a person with a microsoft.com email address, so I'm not sure whether it implies any intention on the part of Mozilla.

As someone maintaining several editor libraries (CodeMirror, ProseMirror) that would benefit a lot from wide EditContext support, I'm still hoping this thing will at some point see adoption beyond Chromium. Is anybody at Mozilla still looking into this?

[masayuki-nakano]

Basically, we're positive for the idea of EditContext because it may make better compatibility between browsers to implement new editable apps.

However, there are some pending spec issues which I filed because I concerned that the issues would block implementing EditContext or potentially risky for new web-compat issues. Additionally, we need to clean up HTMLEditor implementation a lot to support getTargetRanges. So, we don't have any concrete schedule plan to implement it for now.