Browser Based Editing Library
Introduction
Web 2.0 showed the importance of user generated content, but mostly relied on TEXTAREA for input, and encouraged lightweight rich text formats like markdown. Google docs has shown the huge demand for browser based editing, but requires your documents to be on Google's servers, which is a big limitation as many people would like to edit various kinds of documents on their own server. Browser have built in support for editing, based upon early work by Microsoft (designMode, contentEditable, execCommand), but browsers have very poor interoperability, and the feature set is very weak.
There are some pretty good html editors, e.g. Kompozer and BlueGriffon, but these are standalone programs and not accessed through the browser. Some existing browser based editors include TinyMCE, SnapEditor, WYMeditor and YUI Rich Text Editor. Some of these are no longer actively being developed. They all seem to be monolithic and, as far as I can tell, none of them are designed for extensibility as building blocks for specific kinds of applications requiring more than basic rich text support. In particular, I would like to have browser based editing cleanly integrated into the W3C website and our everyday work practices.
This prompted the development of an open source cross browser library intended for use in creating a variety of browser based editors for different kinds of tasks, e.g. regular web pages, minutes, specs, slide presentations, integration with content management systems, etc. The idea is to be compatible with the behavior of widely used word processors like Microsoft Word when it comes to the basics of how backspace, delete and enter are handled. This entails intercepting the key stroke events and overriding the browser's native behavior. In addition, the library provides its own module for handling undo/redo. There is an extensive test suite and a test harness, which has proven critical due to the complexity of the underlying code.
The library currently includes the following components:
- editor.js which provides a sample user interface and application specific code
- edit-core.js which provides the core behaviour for key strokes
- undo.js which implements the undo/redo support, note that it relies on edit-core for getting and setting the caret and a few other operations.
- console.js (optional) redirects calls to console.log to the browser window
- editor.css which provides styling in association with editor.js
- iframe.css which provides styling for the document being edited
You only need to include "editor.js" as this will itself load the edit-core and undo scripts, create the editing UI and load the associated style sheet (editor.css). If the script element for editor.js is in the document body, this will determine where the editor is placed, otherwise it will be appended to the end of the web page.
The editor test bed is still at an early stage of development:
If you are interested in helping with this please contact Dave Raggett <dsr@w3.org>
There is a separate text harness and test suite:
Open Questions
IMEs
How to support native and JavaScript based input method extensions (IMEs)? As an example, you might want to include a Japanese term as Kanji in your English document. Some kind of user interface mechanism allows you to switch to the desired IME. On a US keyboard, you would type ASCII that the IME maps phonetically into Hiragana, and then offers you a choice of relevant Kanji to insert into the document.
Japanese has a very large number of Kanji, so this dictionary isn't something you want to load as part of the editor's web page. You would probably want to support the native IMEs provided by the operating system. Other possibilities include a browser extension, or a lightweight JavaScript module, loaded as part of the editor, that uses dynamic server queries on the dictionary. For many languages the mapping from ASCII to accented characters is small enough to load as a web page module.
DOM3 and DOM4 provide composition events designed to support JavaScript IMEs.
Embedding Metadata for Named Entities
Metadata embedded in HTML can be used to disambiguate which meaning is intended for named entities with multiple meanings. An example is "Berlin" which could be the capital city of Germany or an American new wave band. It should be possible to augment browser based editors with modules that make it easy for users to select which meaning they intend and automatically insert the corresponding markup.
Embedding Metadata as RDFa, Microdata or Microformats
What is needed to make it easy for authors to embed metadata in a variety of formats? Typical use cases include calendar events, or contact details for people and organizations. Could the editor recognize which kind of metadata template is applicable based upon the text in the document? This involves recognizing dates and times, and proper names. Where is the metadata sourced from for proper names?
Future Plans
The immediate focus is on completing the implementation of the user interface and use of HTTP GET, PUT and DELETE for loading, saving and deleting documents on servers. Further out, the aim is to extend the library to support live collaborative editing using web sockets for queues of proposed and accepted changes to documents.
A target application is editing HTML slides. Another target application domain is for distributed meetings with integrated support for chat, HTML based slides, collaborative minute taking, and support for agenda, queue and action/resolution tracking.