Web Editing APIs

One of the fundamental capabilities of the Web is editing the content. WYSIWYG editing was present in the first Web browser, WorldWideWeb (later named Nexus), created by Tim Berners-Lee. Editing, in one form or another, is a characteristic of most interactive sites and webapps, including blogs (for posts and comments), forms (including custom-built "forms"), wikis, forums, online collaborative document editing apps (e.g. Google Docs), and so on.

Each site or webapp that wants editing functionality has to roll its own editing functionality, or reuse an existing script library (of which there are hundreds or thousands, all of varying quality and functionality). Each site has to make its own decisions about what markup is allowed for style and security's sake. Some sites even use a specialized syntax, like markdown or wikitext, to overcome the shortcomings of form-based content creation.

All of this is much more complex than it needs to be.

Editing

HTML5 defines details of contentEditable and designMode, but leaves many functional details undefined. The selection mechanism was removed, deferring to the nascent HTML Editing API spec.

HTML Editing APIs

Work on the HTML Editing API, as started by Google and moved to a the HTML Editing API Community Group, has stalled.

Opinion: execCommand() is incomplete, somewhat arbitrary, unintuitive and not interoperably implemented; it also conflates styling and markup. Rather than try to build upon a flawed foundation, a better, simpler approach may be to accept any tags or properties as input, which could allow for a more extensible and robust system, and to allow the content creator a way to indicate which changes should be in tag markup, which should be inline styles, which should be in a style block (and where), and which should be added to a style sheet (and which one).

Dave Raggett: execCommand is a mess, and the primary value of contentEditable and designMode is probably the ability to place an edit cursor into the document and process all keystrokes. Web application scripts can update the document in an interoperable manner, but currently the problem is the lack of a means for such scripts to interface to the browser's native undo/redo manager. Browsers currently handle certain keystrokes differently, e.g. Delete and Enter. Ideally, this behavior would be standardized, but if that proves impractical, web application scripts can disable the default behavior provided by the browser and manage it themselves. A further challenge is the way browsers handle selections. Firefox and Chrome, for instance, retain selections in contentEditable content, when you click on a button or select element, while Opera does not.

execCommand

The execCommand() method (described in MDN is one approach to making web content editable.

contentEditable

The contentEditable attribute is useful, but not interoperable. In most browsers, only certain kinds of content can be edited (e.g. only Firefox allows editing of tables), and tag boundaries are not consistent.

designMode

Setting this property or attribute on an iframe element makes the document loaded into that iframe editable. This is essentially similar to contentEditable and suffers from the same problems.

Undo/Redo Management

Browsers provide a native undo/redo mechanism, where undo and redo actions can be invoked from the browser's edit menu, the associated keyboard short cuts, or via the execCommand interface. Currently there is no means for changes to documents that are made directly by scripts (excluding execCommand) to be taken into account by the native undo/redo manager. An undo/redo manager interface is needed to rectify this as a basis for a new generation of web-based document editors.

See Aryeh Gregor's UndoManager Problem Descriptions notes (from WHATWG wiki) for more details.

SVG Editing API

SVG has fairly predictable shapes and styling, and there are common UI interface conventions for editing shapes and paths. A very simple set of SVG editing APIs would be useful to anyone who needs basic graphical editing functionality. (More advanced features would be found in authoring tools, of course.)

Saving

Local files

Modified files can be saved locally with existing save dialogs, but an improved file-system access would facilitate real authoring.

HTTP

HTTP 1.1 (RFC 2616) includes a number of methods relevant to document editors, e.g. GET, PUT and DELETE. In addition, HEAD can be used to query the last modified date of a resource as well as its length, and POST can be used for editors that operate on content when the whole document semantics of PUT are inappropriate.

WebDAV

Web Distributed Authoring and Versioning (RFC2518) is an HTTP extension for a set of new methods and headers, for use in editing and moving whole files and directories (collections). This is widely supported and useful for some use cases.

Incremental Ajax Update

Many modern applications have only certain parts of their content editable, and so an ajax-based mechanism for incremental updates would meet a different set of use cases than WebDAV. DOM Mutation events may be used to observe and serialize updates including those made by the browser when cutting and pasting content, or as a result of user keystrokes such as Enter and Delete. Several browsers generate DOM Mutation events for contentEditable/designMode. Current work is looking at replacing DOM Mutation events by a new mutation observer interface. WebSockets together with JSON can provide a resource efficient means for communicating updates.

Collaborative real-time editors

Collaborative real-time editors enable multiple people to view and edit the document at the same time where changes are propagated to all browsers viewing the document in near real-time. Examples include Google Docs and Etherpad. Collaborative real-time editing necessitates a means to synchronize changes made by different users. The local undo/redo manager typically only covers changes made by the local user, but needs to take into account changes made by others as these will effect what local changes can and cannot be undone. This puts further requirements on the undo/redo manager interface if the undo/redo functions in collaborative editors are to be integrated with the browser's native undo/redo mechanism and user interface.

Synchronization may be managed by the server or by the clients. For example, one client can be dynamically appointed to review and merge changes proposed by other clients. The hierarchical nature of the document object model enables the use of algorithms for automated three-way merging of document updates based upon a common ancestor version of a document. Further background is given in the wikipedia article on merging.