What are the most significant benefits of the EditContext API compared to hidden textarea ?

[devlzl]

I am a developer of a rich text editor engine.
I would like to know more about the advantages of EditContext API compared to contenteditable or hidden textarea.

I know that using contenteditable directly on the DOM to implement a rich text editor can lead to inconsistent data and unpredictable behavior.
So I now use a hidden textarea. I get user input by listening to beforeinput, compositionstart/compositionend and update my own text model and selection model, then render them. At the same time, by modifying the position of the textarea element, I make the IME window appear in the appropriate position.
Even when I use canvas to implement 3D art text input, I can also receive input text through a hidden textarea and then render it on the canvas.

So as of now, I'm not sure what significant benefits the EditContext API can bring me compared to hidden textarea?

[DavidMulder0]

As another person responsible for a text editing solution, but not someone who uses an hidden textarea. As far as I know the major reasons I am excited about EditContext are not relevant to you. Here are the remaining ones I can think of:

• IMEs have some control over how they render stuff. E.g. thin/thick underlines, wavy lines, normal lines, etc. etc. EditContext should pass you this information. To get this to work without EditContext you would need to render the text in a visible contentEditable area (which is what we do), but this has it's fair share of issues as well.
• As you have probably experienced by this point, "hacky" solutions are finnicky to get right across all browsers and all operating systems, as there is just a tonne of unique behaviors. EditContext - once implemented across browsers - should reduce these risks, as it standardizes stuff in a far more explicit way.
• One of the hardest things to deal with is that just clicking into a word will for some IMEs bring the entire word into the active edit context. From your description it sounds like you just use the textarea to collect inputs, but for correct support (e.g. for most android keyboards for the 'suggestions') you would also have to put the entire text into the textarea and then set the selection in the right position in the textarea, and then figure out which things you should exactly change in response to input. I think this is equally possible to do with a textarea and EditContext, but EditContext makes the interface between you and the IME explicit, so the chance that you suddenly discover that stuff isn't working is far smaller.

[devlzl]

@DavidMulder0 Thank you for your reply.

Regarding the first point you mentioned, I think we can implement this ourselves. For example, during the compositionupdate event, we can mark the data to render underlines. I'm not entirely clear about where you see thin/thick underlines, wavy lines, normal lines appearing. As far as I know, only IMEs show a simple underline during input. Where do other styles of lines appear?

For the second point, this is actually a concern with EditContext. Historically, different browsers have had inconsistent behaviors with execCommand, and currently, different browsers may have inconsistent selections with window.getSelection().getRangeAt(). However, EditContext is only implemented in Chrome at the moment. Not to mention, we don’t know if or when Safari or Firefox will implement it, and if so, whether their implementations will be consistent.

Regarding the third point, I agree. Since I have almost no experience with editing on Android, the hidden textarea might indeed not solve the problem very well.

[talltyler]

@devlzl is the source for the project you are referring to available online? From the things I have tried it is very difficult to get anything using custom rendering to have access to the IME features correctly without limiting what is rendered to what the browser can natively do or making an editing mode that shows a standard input/textarea. If this is possible, even to get close I would love to see the source code and work on a polyfill to use until the other browsers support this API.

[devlzl]

@talltyler Sorry the code I'm referring to is not open source, but could you please list the limitations you encountered?

[talltyler]

In my production code I'm working around the issue with an editing mode with a normal textarea that is hidden after editing.
I would like to have input and selection rendered in the canvas so that there isn't a jump between the two modes that visually look different but because I've not gotten what you are talking about working I don't have a list for you.

When I've tried using a hidden input I've had difficulty with connection between what is selected and what is rendered and how to place the hidden field so that the IME shows up in the correct space because of the differences in what is rendered.

With any of this I'm also unsure how multibyte characters like emojis or Arabic scripts pair with the concept of selection ranges in strings. I can break the string input into glyphs and graphemes to render but pairing this with selection ranges in strings seems like it could get off. I can maybe see how a system could work to constantly reevaluate between the two could work but then someone enters an IME and a character that was a simple 'o' is now transformed into 'œ' or something. While doing this I've seen issues with key events between browsers and trying to handle the differences between keyboard input, IME changes and keyboard shortcuts unrelated to the field you are in.

There must be ways around this stuff, and I would love hints or links if you have them but also lots of these topics are pretty deep and I welcome new APIs or libraries that wrap up even small parts of this.