I'm not sure what you mean by that, surely word processing is exactly what Quill is meant to be used for? Table use outside of word processing could just be achieved by something other than Quill entirely. It's on the list of nice-to-have features, but not a requirement. I personally don't miss access to tables, since really most of the time tables are misused anyway (for structured presentation of data, there's a ton of times I see tables where bulleted lists or other structures would be a lot more space-efficient anyway). The module system is reasonable for adding in extensions as well. It also means I have per-keystroke autosave and the ability to reconstruct who typed what in a given document on my site, which is important to some of my users. It's not perfect - I don't properly handle some cases with simultaneous edits to the same region, but it's good enough to prevent locking and clobbering in a multi-author environment. By wiring the OT stream into a websocket, I can get pretty decent multi-user simultaneous editing on the cheap. There's a related library that is the rich text specification for operational transforms. I use quill in my big internal CMS / forum mashup project that's not (quite) ready to share yet. The upcoming 1.0 version boasts a much more powerful document model that is being open source separately as Parchment. I think ProseMirror is right to have the document model as a focal point as I've reached the same conclusion with Quill and have worked on to improve for some time now. Extensibility becomes quite limited and often leads to a lot of edge case code. These editors really don't know themselves precisely what content they contain and cannot offer an API for the simple task of inserting text in a specific nth position. Older editors just use the DOM (or HTML strings) and hand that to you as their API. That way no weird/unexpected markup ends up in the editor (whether or not the editor also utilizes contenteditable).Īnother trend is a focus on the document model, which is the editor's main data structure to keep track of content. But it's near impossible to not use contenteditable at all and all editors that I know of (including Trix and ProseMirror) use it to some degree.įor example to handle paste, I've found the best way is to detect a paste, shift focus to another invisible contenteditable div, interpret the pasted content, and insert that into the actual editor through the editor's API. So the major differences would probably be when and where each of these editors tolerate native contenteditable behavior and which implement it themselves. Editors in the last couple of years simply avoid using contenteditable in as many cases as possible.

I would say the old approach was to add contenteditable=true to a, call execCommand for formatting, and try to fix the issues this would cause.

Quill text editor