Finally, a good, open source, cross-browser [1], rich text, real-time collaborative editor for the web! Here is a demo:

[TODO]

[1] IE10+ and evergreen browsers supported

The Ritzy editor is a rich text, real-time character-by-character collaborative browser-based editor. It shuns use of the contentEditable attribute in favor of a custom editor surface and layout engine, exactly like the approach implemented by Google Docs.

In addition, and also like Google Docs, Ritzy is built with real-time collaborative editing support from the ground up, unlike most browser-based editors that require third-party plugins or that do not support it at all.

Ritzy implements all the basic expected text editing functionality, such as bold, underline, strikethrough, superscript, subscript, selection via keyboard and mouse, cut, copy, and paste. More capabilities will be added as needed or as third-party contributions are received.

Limitations and Target Audience

The contentEditable attribute used by most editors allows the editor to delegate the capture of user input and the display of the editor contents and selections to the browser. This is "easy" and performs very well, but is limited and broken by browser capabilities and incompatibilities in contentEditable implementations, and by the underlying HTML data model which is not suited for collaborative editing. Instead, Ritzy implements a custom surface and layout engine like Google Docs:

Let’s start by talking about the editing surface, which processes all user input and makes the application feel like a regular editor. To you, the new editor looks like a fairly normal text box. But from the browser’s perspective, it’s a webpage with JavaScript that responds to any user action by dynamically changing what to display on each line. For example, the cursor you see is actually a thin, 2 pixel-wide div element that we manually place on the screen. When you click somewhere, we find the x and y coordinates of your click and draw the cursor at that position. This lets us do basic things like slanting the cursor for italicized text, and it also allows more powerful capabilities like showing multiple collaborators’ cursors simultaneously, in the same document.

Pros and Cons

Ritzy’s real-time collaborative editing uses a different approach than Google Docs, which based on public information is based on operational transform (OT). Operational transforms require implementing a transform for every operation, and dealing specially with lots of corner cases, especially as the complexity of the model increases.

Instead, Ritzy uses operation-based conflict free replicated data types (CRDTs) to implement the concurrency control required for real-time character-by-character collaborative editing. Just like OT, CRDTs allow changes to happen in different orders on each instance, but the final editor state to converge.

See Collaborative Editing below for more technical details.

Beyond basic text editing, some other features implemented by Ritzy:

• Paragraph flow control, including wrapping support for long words/URLs.

• Selection and keyboard navigation behavior mimicking common platforms like Microsoft Word and Google Docs.

• Multiple author colored/labeled cursor and selection tracking in real-time.

• Cursor blink control simulating browser function (blink while waiting, no blink during operations).

• Cursor slant when traversing italic text.

• Automatically scrolling the document window horizontally and vertically to keep the cursor visible.

• Cut/copy/paste of clipboard data, including conversion between rich text and HTML.

• Focus/blur support with appropriate styling for cursors (invisible) and selections (gray).

• API to control the editor and to obtain selections as HTML, text, or rich text (though more work is needed here).

The editor uses Facebook’s React to manage rendering for the editor surface. React is perfect for this purpose as most user input and selection operations alter the surface only slightly — to insert or remove characters, to highlight selections, and to position the cursor. For each of these, React can instruct the browser to make the minimum number of required changes to the DOM that represents the editor surface. Since modifying the DOM is an expensive operation performance-wise, React is key to Ritzy’s smooth performance. React’s virtual DOM / state abstraction also makes code maintenance simpler.

Managing the layout in JavaScript requires knowledge of the x-y positions of individual characters, for example to position the cursor when the user clicks on text, or to wrap text within the editor’s bounding box.

Ritzy prefers using Opentype.js to obtain the required text metrics from the underlying font, such as advance widths for the glyphs that represent each character.

When the browser/OS platform supports linear subpixel positioning and faithfully follows the font’s instructions for it’s text rendering, the font metrics are sufficient to calculate x-y positions. However, on some browsers on some platforms at some font sizes, for various complicated reasons the font metrics are ignored in favor of hinting or other mechanisms. In these situations, the layout engine falls back to a slower but reliable mechanism using the canvas measureText function.

To use the Opentype.js mechanism, all fonts displayed by Ritzy must be available as TrueType or OpenType font files. Note that Opentype.js does not currently support WOFF font files, but usually TrueType or OpenType equivalents are available. In addition, the font is loaded into memory twice: by the browser and by Ritzy.

Collaborative editing requires each editor client to "report" changes i.e. operations such as inserting or deleting characters, or changing character attributes, to peers. Peers in turn, accept these changes and display them on their own editor surfaces, while themselves dealing with user input and reporting their own changes.

To handle this concurrency, Ritzy uses a CRDT-based causal trees approach created by Victor Grishchenko, running on the Swarm.js library created by the same author. Each client possesses a causal trees "replica" of the current state of the rich text within the Ritzy editor.

Essentially, with causal trees, every character has a unique id, and all operations and positioning is relative to these ids. This greatly simplifies simultaneous operations that are complex with index-based approaches, at the cost of significantly greater disk and memory requirements. This is generally not an issue for text content on modern machines.

Ritzy requires a NodeJS or io.js server running and bidirectionally connected to each editor client via WebSockets or a long-polling mechanism. The server is responsible for receiving changes from all editors and transmitting them back to other editors. A default server implementation is provided as part of the Ritzy project. Currently, Ritzy does not operate stand-alone, though it should not be too difficult to add this capability (see Roadmap).

Unlike other collaborative editing techniques such as OT and diff-match-patch, the causal trees approach is highly amenable to offline editing, therefore offline editing is intended to be a valid use case for Ritzy.

The editor uses JavaScript ES6. Ensure your consuming client and server-side code transpiles to ES5 via babel or similar transpiler, and contains the appropriate ES6 polyfills. See the Ritzy demo for an example.

See client.js or the Ritzy demo for an example of creating and using the editor.

It should be possible to create multiple editors on one page, though this is not yet a tested configuration.

The server-side integration mechanism for most applications employing Ritzy will be to create a Ritzy Swarm.js peer within their server-side application, which will be responsible for receiving all updates to text replicas. The application can then use that text replica for any purpose.

See server.js or the Ritzy demo for an example of this.

Currently, Swarm.js peers only run within JavaScript environments, but the author plans to support other languages in the future.

See also Commercial Features (Future).