The WHATWG Blog

Please leave your sense of logic at the door, thanks!

The Road to HTML 5: contentEditable

by Mark Pilgrim, Google in Tutorials

Welcome back to my semi-regular column, "The Road to HTML 5," where I'll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.

The feature of the day is contentEditable, by which I mean client-side in-browser "rich text" editing. All major browsers support this now, including Firefox 3, Safari 3, Opera 9, Google Chrome, and Internet Explorer (since 5.5). Of course, the devil is in the details.

In this article:

What is contentEditable?

There are really two attributes involved, designMode and contentEditable. The designMode attribute governs the entire document (i.e. it makes the entire document editable, like a dedicated HTML editor). The contentEditable attribute governs just the element on which it appears, and that element's children -- like a rich text editor control within a page. In fact, that was the original use case: enabling web developers to build rich text editors. There are now a variety of such editors available under various licenses.

Both of these attributes, designMode and contentEditable, were originally designed and implemented by Microsoft in Windows Internet Explorer (5.5, to be exact). There was some superficial documentation on how to use them (so developers could develop rich text editors), but little thought of interoperability. So, no details on all the nitty gritty details of exactly what markup is generated when you press ENTER right here, or what the DOM looks like as you backspace your way through a start tag. Much of this sort of information was later reverse-engineered, and cross-browser support for basic operations is actually quite good. (Browsers still vary widely on the details.) The designMode and contentEditable attributes, and the APIs that drive rich text editors, are implemented in all major browsers, including Firefox, Opera, Safari, Google Chrome, and of course Internet Explorer.

How does it work?

Mark Finkle wrote a nice high-level summary of designMode, and later added a post about contentEditable once it appeared in the Firefox 3 alphas. (That was back in 2007.) Quoting Mark:

Mozilla has a rich text editing system (called Midas) and an API similar to Internet Explorer's. Mozilla, like Internet Explorer, supports the ability to make an entire document editable by setting the designMode property of the document object. Once in design mode, the document can be manipulated using various DHTML commands.

... Firefox 3 is expanding its rich WYSIWYG editing capabilities by adding support for the contentEditable attribute. Setting contentEditable to "true" allows you to make parts of a document editable. ...

The API for interacting with the document is:

document.execCommand
Executes the given command.
document.queryCommandEnabled
Determines whether the given command can be executed on the document in its current state.
document.queryCommandIndeterm
Determines whether the current selection is in an indetermined state.
document.queryCommandState
Determines whether the given command has been executed on the current selection.
document.queryCommandValue
Determines the current value of the document, range, or current selection for the given command.

Once you have an editable document (designMode) or element (contentEditable), you use this set of API calls to issue "commands" on the editable region, and to query the current state of the region. Commands are things like "bold," "italic," "underline," "create a link," "change foreground color," and so on -- all the commands you would expect from a rich text editor. Here's a test page with 36 commands.

In other words, "supporting the contentEditable attribute" is really just the tip of the iceberg. The real compatibility story is written in the commands which are passed to the document.execCommand() function. So which browsers support which commands?

As you can see from Peter's chart, basic stuff like bold, italic, creating links, and changing colors is well-supported across browsers. After that, the compatibility story gets hairy.

A brief and extremely biased timeline of standardization

Reverse-engineering and standardizing contentEditable and its associated APIs was one of the original goals of the WHAT working group, as part of (what at the time was called) "Web Applications 1.0" and is now known as "HTML 5."

Conclusion

The original use case for contentEditable -- building rich text editors -- is alive and well on the web. Cross-browser compatibility can be charitably described as "evolving," but we are long past the point where "only IE can do that fancy rich-text stuff." Standardization through the WHATWG has shaken out numerous interoperability bugs and led to thoughtful consideration of a wide variety of edge cases. Most of these benefits had to be realized through reverse engineering, rather than cooperation, but the work has been done and the web is better for it.

Further reading

↔

17 Responses to “The Road to HTML 5: contentEditable”

  1. Both of these attributes, designMode and contentEditable, were originally designed and implemented by Microsoft in Windows Internet Explorer (5.5, to be exact)

    While the attributes came in 5.5, the functionality came earlier. The DHTML Editing Control triedit came as an ActiveX download for IE4 and was shipped with IE5.

  3. Has there been any discussion about what pressing enter should generate? Firefox, IE and Opera (<9.5) insert BR elements, but Opera (9.5+) and Webkit just seem to split whatever block-level element the cursor is in, creating one if it doesn’t already exist.

    This can be extremely painful if you’re trying to style columns or a template of any kind.

  7. Why do you think mobile browsers under iPhone and Android doesn’t implement it? the iphone UITextView is indeed a UIWebView and in pre 3.0 devices you could run even javascript.

  11. A great write up of the current situation. I’m still shocked that more progress hasn’t been made. I have worked on various CMS systems that use contenteditable and it is a painful experience. I can’t wait to see a standard cross browser implementation.

  13. For some reason the contentEditable attribute is not supported in Safari on iPhone OS.

  15. Aloha Editor uses extensively the contenteditable Attribute plugs directly in the DOM and tries to deal with the browser issues (bug, different handling of formattings, selection and the more) and provides an flexible plugin interface for extensions. Try it out. Feedback appreciated!

  17. To do with the differences between browsers, I use extensive and strict filtering. Basically I break down the generated HTML, mercilessly filter any tags that are not needed/allowed, and reduce everything to line-breaks.
    It works. I am hoping that the new HTML5 spec will standardize the behavior across browsers and remove the needs for all this. Anyway knows where I can find the HTML5 specs, in a somewhat dumbed down version? I could go through the official documents, but I’d rather like something that is easier to read.