Rich-Text Editing LAPI

[jamiebuilds]

Rich text editors are one of the most common extremely heavyweight components that web apps ship today. They are found in almost every web app that has user generated content today and they will frequently weigh 500kB or more.

Further, they all have slowly started to work in roughly the same way:

• contenteditable region
• Represent content as an AST (or "document model")
• Render the AST using pre-defined components for each node type in the tree
• Input/mouse events prevent default behavior and get transformed directly into an AST and trigger a re-render

A LAPI would have to expose:

• A base "document model" that can be extended with custom node types
• Default renderers for every document node type that can be customized
• Default event handlers for common operations that can be customized
• APIs for controlling the editor (including selection, text/cursor operations, serialization apis, etc) programmatically
• A readonly mode

Ecosystem:

• https://prosemirror.net
• https://draftjs.org
• https://trix-editor.org
• https://quilljs.com
• https://www.tiny.cloud
• More complete list: https://github.com/JefMari/awesome-wysiwyg

[jamiebuilds]

Does this feature need new low-level capabilities to work successfully?

No, this is possible to do with only the technologies provided by the web platform today.

Can this feature stand on its own, or does it require integration into existing APIs?

It can be done as an entirely separate API, most likely as a new web component.

Is this feature tricky to implement performantly or correctly?

Yes, most companies are not able to implement it on their own, which is why you can find several editors that are closed source and require licenses.

Do the APIs for this feature vary wildly across the JS ecosystem, or have they mostly settled down?

Most newer rich text editors that have come out in the last few years have largely worked in the same "document model" way. Historically, many tried to normalize browser behavior with contenteditable but that has proven to be difficult.

Does this feature involve a lot of styling choices for its UI?

The default editor could ship with only a contenteditable element which could have no styling past what the web already ships with. Users can add their own controls and styles if they want them (they almost all will).

Will this feature be used commonly, or rarely?

This is a super common feature of web apps today, basically every site with user generated content will have a rich text editor to some degree, from Twitter's new tweet input with #hashtags and @mentions to Dropbox Paper with a full document editor, at the root they are largely the same thing.

[littledan]

Maybe this would make more sense after work by The Editing Taskforce is a bit further along, and there's good compatibility between browsers on how editing works.

[Reinmar]

The Editing Taskforce's main goals right now is to open the contentEditable black box with a lower-level or simply more granular APIs for building RTEs. That's driven mainly by requirements coming from the authors of JS RTEs (me included) and there are many fields where we need to significantly improve web standards in order to make building an RTE a less of a nightmare. Looking at the issues that we're facing in the Editing TF and how many years it took to even get to the current point (not even half-way), that's still going to take some good time. The result will be, hopefully, a set of APIs which will allow reducing the complexity of our RTEs, but not the size of them, unfortunately.

In parallel to that, some big players like Google and Microsoft are thinking about completely opening the "editing APIs" by introducing low-level primitives. I think that that comes from the experience that they have with developing tools such as Google Docs or Office 365 where much finer control on various editing aspects (such as page rendering, selection rendering) is needed. While, as CKEditor 5's developer I'd might like to use some of those low-level APIs the biggest problem that I see is that using them will most likely require a lot more code and a lot more knowledge about text editing (IMEs, BiDi, i11n in general, platform-specific issues, etc.). So, if things will go wrong, those APIs will not be approachable for even medium-sized players. Therefore, my personal goal is to make the best out of it – low-level APIs that will be usable for "normal" developers.

Now, is any of the groups that I mentioned interested in working higher-level APIs at the moment? This is my personal opinion, but looking at the direction of Editing TF's actions, I'd say no. I'm not saying that that won't happen, but the focus right now is on solving bazillion other problems that we have and the complexity of this topic makes this process slow. In a couple of years, once we get to a point where we can say "ok, it works!", we might start thinking about the RTE LAPI.