We are reviewing today.. One question I had was about the security & privacy questionnaire. It seems like this technology would have signifigant access to sensitive information... 2.4 and maybe needs to elaborate on how it would mitigate against misuse / elaborate possible abuse cases?

Dan was worried about the access to sensible information. I assume though, that this will only work with input methods shipped with the browser, like emoji picker and accessibility helpers.

This is an API for the web site author to integrate with these, and not a way for developers to create their own input methods that will then get access to sensible information such as selected text/passwords etc.

Maybe this could be made more clear early on in the explainer

My definition of sensitive data would be any information conveyed by the user to the site that the user didn't explicitly intend to provide.

In the case of EditContext, which deals with delivering text that has been input by the user to the active document, I expect that the user's intent is to provide the site with the text that has been typed on a keyboard, or composed in an IME, or spoken to an OS speech to text input mechanism, etc. EditContext doesn't expose any of the details of how the text was provided directly, only the resulting text and some direction as to how the text should be decorated during the process of composition.

The text data input by the user is already available through alternative means, e.g. the beforeinput event; the EditContext is just providing it in an alternate way that is decoupled from the DOM. The decoration information seen in the IDL as part of the TextFormatUpdateEvent is new, but we don't consider it sensitive.

If there is a threat to be considered for formatting information, it would be that an author may differentiate one input method from another based on the conventions that the input method has adopted for formatting its text during composition. For example, speech input may use a dotted gray underline while a Japanese IME would use a solid black underline. This formatting data is necessary for sites like Google Docs and Office Online to meet user expectations during text input, and we believe its acceptable to expose this information to web sites so that the user can input text in a way that is consistent with their experience.

Note that there are other mechanisms already that may reveal similar information about the user. One example are the heuristics by IMEs to suggest candidates for some phonetic input that are most frequently selected by the user. The first candidate after typing the phonetic input will be inserted into the DOM and visible to the author's script. While this may provide some new bit of information to fuel fingerprinting, it allows the user to have a fast and consistent input experience, which IMO outweighs the minor privacy concern.

I hope this helps. If this is the information you're looking for we're happy to include it in the explainer. If you need more or disagree with any of the points we've raised please let us know.

Thanks!

@atanassov and I discussed this during the VF2F.

From a high-level perspective, we are happy with this proposal. It's a complex, previously unaddressed problem and we are glad to see someone working on this.

I personally would like to see how this is expected to behave in corner-case scenarios, and what chain of events come out in different user scenarios across different languages (e.g. non-compositing, compositing without candidates, and compositing with candidates) to better understand if we are actually solving this problem once and for all.

As for the privacy issue noted above, we discussed this at length and concluded that this is probably a non-issue.

Nit discovered by @hober during F2F review: There seems to be a typo/error in Example 1 and Example 3, the former references EditView but the implementation is named EditableView.

Also, are this.computeSelectionBoundingBox() and computeSelectionBoundingRect() supposed to be the same thing? If so, what is it? Is it the bounds of the current selection, or is it the bounds of the editable area within which selection can occur?

This looks promising, but it's a very complex API and the explainer is quite terse and seems to omit a lot of detail, so it's hard to review the details of the API.

For example:

Additionally, the layout bounds of selection and conceptual location of the EditContext in the view should be provided by calling updateLayout.

window.requestAnimationFrame(() => {
    editContext.updateLayout(editContainer.getBoundingClientRect(), 
                             computeSelectionBoundingRect());
});

I'm not quite sure what this is doing. Update the layout of what? Why does it take these two rectangles? Why does it need to be done asynchronously (via rAF)?

In general, it would be helpful at least if the IDL had extensive comments explaining the purpose of each enum, object and method. The code examples could also use more extensive comments to explain each call into the proposed API.

Also, it would be great to illustrate via targeted (minimal) code examples how the API solves each of the problems listed in the Real-world Examples section. That section is extremely helpful to understand the context of the API, but it's not made explicit how the API solves those problems.

Additionally, it's a bit unclear how this would work with RTL languages, since it involves selection and selection behaves differently there. Do you have any thoughts on this?

Apologies for not responding to these questions earlier. We have been working with web devs and other Browser vendors to figure out all the intricacies related to selection (e.g RTL selection movement, word break etc), editing commands, accessibility etc. We are working on updating the explainer with more detail texts & examples. We will update the status here once we have addressed all the concerns. Thanks for all the feedback so far! Tagging @alexkeng who is actively working in this space.

@cynthia and myself took another look at this proposal during our May 2021 vf2f and we are still waiting for more context from the authors. Please let us know when you have updates and are ready to discuss further.

@LeaVerou and I refreshed this again during our Gethen vf2f. We still don't see observable progress. @snianu if this work is still ongoing we would like to know otherwise we will close the review as stalled.

sorry for late response. This work is still ongoing and here is the latest explainer

@cynthia

I personally would like to see how this is expected to behave in corner-case scenarios, and what chain of events come out in different user scenarios across different languages (e.g. non-compositing, compositing without candidates, and compositing with candidates) to better understand if we are actually solving this problem once and for all.

We have updated the EditContext Event Sequence section in the explainer and added a new section Difference between Contenteditable element and the EditContext element with a summary table for events in various editing scenarios. Please see the explainer for more details about the event behaviors.

There seems to be a typo/error in Example 1 and Example 3, the former references EditView but the implementation is named EditableView.

The old examples are obsolete and replaced with 4 new code snippets and 2 sample pages.

Additionally, it's a bit unclear how this would work with RTL languages, since it involves selection and selection behaves differently there. Do you have any thoughts on this?

We haven't really tested RTL languages. We will get back to you when we have more info.

@hober

Also, are this.computeSelectionBoundingBox() and computeSelectionBoundingRect() supposed to be the same thing? If so, what is it? Is it the bounds of the current selection, or is it the bounds of the editable area within which selection can occur?

yes, they are the same, and it's the bounds of the current selection (The old examples are deleted, but the sample of updateLayout can be found in Example 4)

@alice (though she is unassigned)

I'm not quite sure what this is doing. Update the layout of what? Why does it take these two rectangles? Why does it need to be done asynchronously (via rAF)?

It doesn't have to be done asynchronously, please see the comment in Example 4 for more details.

In general, it would be helpful at least if the IDL had extensive comments explaining the purpose of each enum, object and method. The code examples could also use more extensive comments to explain each call into the proposed API. Also, it would be great to illustrate via targeted (minimal) code examples how the API solves each of the problems listed in the Real-world Examples section. That section is extremely helpful to understand the context of the API, but it's not made explicit how the API solves those problems.

Thanks for the suggestion! We have added more comments in the new examples, which should help explain things a litter better. As for adding code examples to show how the API solves each of the real-world problems, we do have some prototypes that show how EditContext can address these scenarios, ex. using EditContext for composing across page boundaries, and collaborating while composing text, but some of them are quite big samples and involve some open source projects. We'll evaulate it and update the explainer with appropriate ones.

I'm questioning why this is built around a plain text buffer model. What happens when the element that an EditContext is attached to has children? This API seems to fall down hard in that case.

More specifically, rather than using text offsets, and a string, why not use DOMRange and DocumentFragments? I accept it adds some complexity, but ti also serves the use case of actually editing a web page.

@plinss I think it's because the OS text input services only understand plain text. When interacting with IMEs, browsers serialize the DOM into plain text view and send it to the IMEs via system APIs provided by the OS text input services. EditContext is a web API that lets authors have control over what part of the content to serialize and when to communicate that to the IMEs. This model is described here in the explainer.

I understand that the OS services have a text based API, but it still seems that the behavior with elements that have children is underspecified. Regardless of what the behavior is, if it's not specified it's not going to be interoperable.

Also, any answer to the question about using DOMRange? (You might also want to look at pending improvements there

We're just picking this up today to try to see if we can close. It looks like we're still pending an answer to the questions @plinss raised above.

@torgo Apologies for the delayed response. @alexkeng is working on updating the explainer and spec with all the details. We will update this thread once we have addressed all the concerns.

but it still seems that the behavior with elements that have children is underspecified. Regardless of what the behavior is, if it's not specified it's not going to be interoperable.

Yes, this is something that we've discussed internally and added more details about it in the explainer and the spec that we are working on right now. Once we have addressed all the feedback from the developers, we can post the updated docs here. Thanks for raising this concern!

Ok thanks for that! We'll re-review and close when we get a chance to look at those updates.

Hi @snianu I notice no updates since 8-November. Does that mean you're ready for us to re-review? Thx!

Hi @torgo, no, EditContext is not ready for re-review, in fact, the project is on hold at the moment due to resource constraints. We'll update the ticket when we re-start the project, thanks!

Ok - in that case I think we're going to go ahead and close this one. Please ping the issue or a TAG member directly when you think it's ready to be re-opened. Thanks!

@torgo @dandclark is now actively working on EditContext and has been updating the spec as well. Requesting to re-open this issue to continue TAG review for this feature. Thanks!

こんにちは TAG-さん!

Apologies for the extended delay here. We've got capacity to pick up this spec again, and I'm going to take point on driving it.

Can this issue be reopened, or should I file a new issue for the review?

The spec draft for the feature has evolved quite a bit from when this was initailly opened, and some of the materials have moved around. @snianu's top post has been edited with the new links, or you can find the spec draft directly here.

To start addressing some of the last questions on this thread from @plinss, the intended behavior when an EditContext has children is that there will be a mix of behavior borrowed from contenteditable and some behavior that diverges. This section overviews these similarities and differences: https://w3c.github.io/edit-context/#edit-context-differences.

Essentially, the browser will handle caret navigation, and child content of the EditContext will inherit editability such that the user can click/arrow-key into it and move the caret around in it. Where EditContext primarily differs is that when the user tries to add or delete content via key or IME input, the browser will not modify the content automatically. Instead it will fire events against EditContext so that the page author can perform the modification as they see fit.

A primary goal of this API is to give the author a primitive to interact with OS text input services more directly. This is done via a plain text buffer since that's what the text input services use. The authors are then responsible for translating this into the view that will be presented to the user, either building it with DOM nodes or painting to a <canvas>.

@torgo tagging you directly about the request to reopen since I don't know if there's much visibility for closed threads. Thanks!

(I went ahead and reopened, hope that's ok.)

Relevant issues:
https://github.com/w3c/edit-context/issues/38
https://github.com/w3c/edit-context/issues/53
https://github.com/w3c/edit-context/issues/54

Thanks for the updates, at this point we're going to close as satisfied. I have a few personal concerns about usability, but I think experience working with the API will be the determining factor there. My primary concern was avoiding under-specified behavior and that seems to be addressed now. Thanks for flying TAG.