How to hack your app to make contenteditable work

The mission? Build a rich text editor widget using contenteditable. Mark Pilgrim described this contenteditable use case as “alive and well on the web” with the warning that it is still “evolving”. Nevertheless, because of various problems we had using an <iframe> our group decided to switch from using designMode to contenteditable.

Note: this article has been updated several times to add up-to-date information as it becomes available. Please add your tips and tricks or any corrections as a comment.

Most of the issues are in the Mozilla editor implementation. IE and WebKit seem to work fine.

Mark’s document is an excellent resource, but now it’s time for a reality check. Here are some problems I had to work around in Firefox 3.5 beta 4:

1. Large caret,  tiny caret, no caret, or two carets on initial focus.
   Workaround: ensure the magic sequence of <p><br/></p> as end-of-document content. Watch everything that happens to make sure it’s never changed, removed or even selected. (Bonus: this is also the fix for several other items in this issues list). Don’t let the caret go after it. If selection ends up extending past it, then just use window.selection.extend to move just before the caret. If the selection had been “collapsed” (just a caret), then set the caret before it (for example set the start before andthen  use window.selection.collapseToEnd to make the selection match).
2. Many execCommand commands, such as bold, do not work after select all, or may have issues when the caret is at the end of content.
 Workaround: the fix for item #1 above also addresses this.
3. The “indent” and “outdent” execCommand will actually indent the entire contenteditable region! 
Workaround: the fix for item #1 above also addresses this.
4. Caret and selection are not restored when you tab or click out of the contenteditable area and later tab back in.
   Workaround: store selection onblur and onmouseout, and restore onfocus. Unfortunately onblur was not enough, because by the time the user has clicked outside of the editable area, the selection has already been forgotten.
5. Double clicking on any HTML Form input in the same document as a contenteditable no longer selects a word.
   Workaround: you have to cleverly set contenteditable=”false” on all area in the document onmousedown in the inputs, and then set them back to “true” as soon as possible.
6. You can paste the editor back into itself etc. This is arguably a feature, not a bug, since contenteditable could be used to develop web authoring tools. However, it’s something to be aware of.
   Workaround: create styles for all children in contenteditable for overflow: hidden !important. You’ll need to think about what styles to override. Remember that users can drag or paste in comment from anywhere.
7. Can’t select text and do operations such as delete if the text includes the beginning or end of the content.
   Workaround: make sure the root editor element is a <div>. Style it how you want (e.g. display: inline), but if it’s a <span> at least, this bug will occur.

My team is still discovering some issues, but they are harder to reproduce. Sometimes the editor becomes unfocusable and it becomes impossible to do further editing. I’m not sure what gets it into this state.

There are over 70 filed contenteditable bugs, and when I am done filing there will be more. The fact that most of these bugs were not yet filed by anyone else yet seems to indicate that contenteditable just isn’t being used much out there. I can see why, and unless the issues get cleaned up, it will stay that way.

The low quality of contenteditable support is unacceptable, especially for something that shipped in a previous version of Firefox. There was plenty of time between Firefox 3 and 3.5, to circle back, gather what was learned, and fix the most important bugs. Yet, I could only find 7 behavior-related contenteditable bugs fixed since June, 2008. That means it’s mostly being allowed to exist as it is.

I would like to make an observation, after 8 years working on the Mozilla code base, and now as a developer of web applications. Please don’t read on if you are allergic to sports analogies, or if you just want to hear how great Mozilla technology is. Quality would be higher if there were one or two fewer  initiatives for the Next Great Leap, and more concentration on just fixing the old boring bugs. There are obviously a lot of big world-changing initiatives going on at Mozilla, and there should be. However, as a community we should be realistic that three point shots are awesome when they go in, but they are easy to miss. Lots of simple plays, like rebounds and layups, are still necessary. Sometimes I think that fundamental bug fixing gets lost in the drive to make news headlines. Honestly, you don’t have to go that far out on the edge to find problems. I don’t believe this is an engineering issue. I think it’s actually Mozilla’s leadership not wanting to pour resources into what seems like an endless problem where great results don’t provide immediate mind-share benefits. However, as we all know, this stuff is super complicated, and in order for the web to move forward things have to “just work”. Either Mozilla has to fix the behavioral bugs or every web developer who uses the feature has to track down what the problems are and try to find a hack for it.

P.S.  FWIW, other than selection memory, WebKit has worked perfectly so far.  That said, Mobile WebKit for the iPhone has a major issue. It doesn’t actually support contenteditable at all. Worse, it reports that it does — node.contentEditable and node.isContentEditable are true for a node with the attribute contenteditable=”true”, yet . So if you want a fallback, you have to sniff for the user agent rather than use the technique of capability detection, which is better because you never know which future version will support contenteditable.