There’s the third way of inserting the text into the editor. It seems like a way round, a hack. You can call a fake Delete keydown event and only after that insert the text. In doing so, the editor performs all the necessary actions to delete the text correctly and we just have to insert a new text into a predefined place. But it’s risky and insecure in the long run. We have to continually monitor how editors behave in this case and we should always be ready to invent new workarounds.

The ideal situation would be if editors allow making text insertion in the first two methods ( Range API and document.execCommand ). The developers of CKEditor 5 intend to do this. ProseMirror, Quill and Trix already support these methods. We hope other developers will support this idea and make the necessary adjustments.

Otherwise, we face a vicious circle just like with cross-browser issues when developers of browsers put bugs and incompatibility issues on a waiting list or choose to ignore such problems. But now it’s us who need to invent a roundabout way to provide a normal interaction. This is because editors support browser APIs in varying degrees.

The developers of modern editors are tired of fighting with browser incompatibilities. They’re exhausted to use imperfect built-in APIs. They chose to put aside these problems, get more control and provide users with more opportunities. They’re absolutely right, however, they don’t have to ignore the problems third-party developers have faced — the cross-editor incompatibilities turned into another headache for us.

Pills for a headache

There are several scenarios of solving these problems.

The ideal scenario is described above and it implies fixing the way of how editors respond to the text insertion using standard browser methods.

Also, it’s possible that editors may enable users to work with their instance objects and use their APIs, however, they should make these APIs similar, cross-editor as does CKEditor 5. It seems to be the most complex option and the developers of editors are unlikely to choose it, however, we added it to the list of possible scenarios.

The providers of spell-check and similar solutions may also help other developers using these editors alongside their spell-check tools. Everything rarely goes smoothly: in some cases you need to have a greater control over the text insertion or reject it if necessary. For this purpose, we call the custom event on the editable element ( customInsertText ). This event is called prior to the text insertion and it has additional data related to the insertion.

Developers can add listeners to this event, extract useful information from it and, if necessary, reject the text insertion. And they can either do this using built-in mechanisms of a certain editor (native APIs) or don’t do this at all, if the situation so requires.

We’ve already implemented this mechanism in our application and we’ve tested it on the Draft.js editor. You can read a short description of this approach in the comments in the Draft.js editor GitHub repo.

Forced evolution to the bright future

To support modern editors, we had to switch from the standard straightforward way to the alternative approach that implies using a virtual layer. As a result, we applied this approach to lots of other editable elements. It turns out to be more efficient than the former one.