To make a web page editable, IE provides two methods. One of them is setting document.designMode = “on”, which can only be applied to the entire document. And the other method is setting contentEditable = “true”, which can be applied to any HTML elements. The good part of the first method is that the same syntax can also be used for Firefox, which is why I prefer using the method. According to the document located at http://msdn2.microsoft.com/en-us/library/ms537837(VS.85).aspx, setting document.designMode = “on” and document.body.contentEditable = “true” are supposed to have exactly the same effect.
And it did look like they do
But as I go on and do more things with the editor, I started to make some disturbing discoveries. The first weird thing I noticed was that if the document.domain property was set for the document, I don’t get to access the editing area as the browser would throw an “access denied” exception. I’m sure that this should not have anything to do with the cross-domain issues because
1. The same domain value was set for the outer document and the editing area (iframe).
2. Firefox does not complain.
3. It works fine if I used the second method and make use of the contentEditable property.
And the next thing I discovered is that those two methods react differently to the lines that the source code looks something like <p> </p>. The designMode method would take it as a blank line. But the contentEditable method would take it as a line with a “space”.
These behaviours are not documented anywhere and took me such a long time to pin point what is causing the differences. And I believe that there must be more “subtle” differences between the two, which would cause someone to spend a hell of a time. So, if any of you reading this, discover any other differences, it would be very appreciated if you would share your knowledge here. 😀
Should I go for designMode or contentEditable for my editor?
It has been such a confusing time for me. Then, I saw this article http://starkravingfinkle.org/blog/2007/07/firefox-3-contenteditable/, which says that Firefox will have support for contentEditable property for the next major release. And now, my guess is that the designMode would slowly fade away as contentEditable is “supposed” to do the same thing and some more. So, yes, my decision for now is the contentEditable for IE/Safari and designMode for Firefox until the support is added.
6 Replies to “Differences between designMode and contentEditable”
One major difference I found as I tried to set body style for the iframe: if you use contentEditable, body node is exposed to you. While if you use designMode, IE would not present it.
The following code works to change the default font of the iframe:
editor = document.getElementById(‘ifrm’).contentWindow;
editor.document.body.contentEditable = true;
editor.document.body.style.fontFamily = ‘Courier New’;
But if you change the 2nd line to:
editor.document.designMode = “on”;
IE will complain the body node not found.
Thanks for the very useful info, exactly what I needed when I needed it.
I have found another big difference: When using “designmode=on” IE does not fire onpaste or onkeydown events within the iframe. With “contenteditable=true” the events are fired.
The actual version of Firefox supports “contenteditable=true” by now, so I decided to you this in my editor.
I found two other differences.
1) sometimes the iframe will be focused automatically when use contentEditable in IE6 and IE7, IE8 has not the problem.
2) the contextmenu has not copy and cut functions when use designMode in IE.
One major difference i found with “designMode” is that, Firefox4.0 wont fire any keyevents(keyup,keydown,keypress) on the editable document, but in remaining browsers working fine.
Another small difference is that IE seems to use a different text selection method for designMode than it dose for contenteditable.
The designMode selection method will sometimes not allow you to select text on elements that come after certain elements in IE9 (it seems rare but happens). The contenteditable selection method seems to work fine all the time.