Scribe

A rich text editor framework for the web platform, with patches for browser inconsistencies and sensible defaults.

For an introduction, you may want to read the blog post Inside the Guardian’s CMS: meet Scribe, an extensible rich text editor.

Please note: There is a lot of missing documentation for Scribe and many of its plugins. We plan to improve this, however in the meantime we encourage you to look at the code. Scribe is very small in comparison to other libraries of its kind.

See an example.

Core

At the core of Scribe we have:

• Patches for many browser inconsistencies surrounding contenteditable;
• Inline and block element modes.

Patches

Scribe patches many browser inconsistencies in the native command API.

Modes

Natively, contenteditable will produce DIVs for new lines. This is not a bug. However, this is not ideal because in most cases we require semantic HTML to be produced.

Scribe overrides this behaviour to produce paragraphs (Ps; default) or BRs (with block element mode turned off) for new lines instead.

Installation

bower install scribe

Alternatively, you can access the distribution files through GitHub releases.

Options

allowBlockElements

Enable/disable block element mode (enabled by default)

Usage Example

Scribe is an AMD module:

require(['scribe'], function (Scribe) {
  var scribeElement = document.querySelector('.scribe');
  // Create an instance of Scribe
  var scribe = new Scribe(scribeElement);
  
  // Use some plugins
  scribe.use(scribePluginBlockquoteCommand());
  var toolbarElement = document.querySelector('.toolbar');
  scribe.use(scribePluginToolbar(toolbarElement));
});

You can see a live example here, or view the code here.

Architecture

• Everything is a plugin.
• No large/unecapsulated dependencies. The only dependency is lodash-amd, however the partials used from this library are bundled with the distribution.

A plugin is simply a function that receives Scribe as an argument:

function myPlugin(scribe) {}

A consumer can then use your plugin with Scribe.use:

scribe.use(myPlugin);

Plugins may package whatever functionality you desire, and you are free to use native APIs to do so. However, you are required to wrap any DOM manipulation in a transaction, so that we can capture state changes for the history. For example:

function myPlugin(scribe) {
  scribe.transactionManager.run(function () {
    // Do some fancy DOM manipulation
  });
}

Browser Support

Theoretically, Scribe should work in any browser with the Selection API, the Range API, and support for most of the non-standardised list of commands that appears in this MDN article. It has been tested in Firefox >= 21, Chrome >= 27, and Safari 7.

See the status of our integration tests for more up-to-date support information.

Commands

Commands are objects that describe formatting operations. For example, the bold command.

Commands tell Scribe:

• how to format some HTML when executed (similar to document.queryCommand);
• how to query for whether the given command has been executed on the current selection (similar to document.queryCommandState);
• how to query for whether the command can be executed on the document in its current state (similar to document.queryCommandEnabled)

To ensure a separation of concerns, commands are split into multiple layers. When a command method is called by Scribe, it will be filtered through these layers sequentially.

Scribe

Where custom behaviour is defined.

Scribe Patches

Where patches for brower inconsistencies in native commands are defined.

Native

Plugins

We have created a collection of plugins for advanced rich text editing purposes, all of which can be seen in use in our example.

• scribe-plugin-blockquote-command
• scribe-plugin-formatter-plain-text-convert-new-lines-to-html
• scribe-plugin-curly-quotes
• scribe-plugin-heading-command
• scribe-plugin-intelligent-unlink-command
• scribe-plugin-link-prompt-command
• scribe-plugin-sanitizer
• scribe-plugin-smart-lists
• scribe-plugin-toolbar

FAQ

Is it production ready?

Yes. The Guardian is using Scribe as the basis for their internal CMS’ rich text editor.

It is likely that there will be unknown edge cases, but these will be addressed when they are discovered.

Why does Scribe have a custom undo manager?

The native API for formatting content in a contenteditable has many browser inconsistencies. Scribe has to manipulate the DOM directly on top of using these commands in order to patch those inconsistencies. What’s more, there is no widely supported command for telling contenteditable to insert Ps or BRs for line breaks. Thus, to add this behaviour Scribe needs to manipulate the DOM once again.

The undo stack breaks whenever DOM manipulation is used instead of the native command API, therefore we have to use our own.