Re: [w3ctag/design-reviews] EditContext API (#416)

sorry for late response. This work is still ongoing and here is the [latest explainer](https://github.com/alexkeng/editing/blob/gh-pages/docs/EditContext/explainer.md)

@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](https://github.com/alexkeng/editing/blob/gh-pages/docs/EditContext/explainer.md#editcontext-event-sequence) section in the explainer and added a new section [Difference between Contenteditable element and the EditContext element](https://github.com/alexkeng/editing/blob/gh-pages/docs/EditContext/explainer.md#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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/416#issuecomment-921606537