Blogging from the Server Side

UPDATE: Based on Doug's comments below, I revised this post on 2/20/2008 to clarify what functionality is provided by the editing features supported by the major browsers.

If you write content for the web, chances are you use a rich text editor for writing your material.

The rich in the name refers to the ability to apply styling to the content via mouse click operations. For example, to make the text bold, you click on a toolbar button, usually with the letter "B". To anchor a hyperlink to some text, you click on another toolbar button that interactively asks where the link should point to. You get the general idea.

HTML 4.01, as spelled out in the W3C specs, doesn't give you this functionality for free. All it supplies are INPUT and TEXTAREA form elements, and these are just vessels for containing plain text. So how do web based rich text editors work their magic?

The two major browser architectures, Microsoft's Internet Explorer and Mozilla's Firefox, provide an infrastructure for interactively editing elements.

Through the use of JavaScript or HTML attributes, web page content can be made to be editable. This includes structural elements like divs, not just the standard form elements. Moreover, the technologies gives web developers a handle for executing edit commands against HTML, so you can do things like insert hyperlinks and images.

Editability allows developers of rich text editors, like the YUI Editor and FCKEditor, a way to layer JavaScript on top of this foundation to create a customizable toolkit. Web application developers, like Compendium, can then customize these editors to support additional features, like draft submission and keyword strength calculation.

As powerful as these toolkits and the browser APIs might be, there are times where you can run into glitches. I uncovered one such case recently while troubleshooting some problems that users were encountering with Internet Explorer.

Suppose you have an editable HTML document, that contains an image (something with an img tag). With IE, you can click on the image and get some resize handles, like this:

As you can see, there are little squares on the perimeter of the image's edges. Grabbing and dragging these edges allow you to adjust the size of the image interactively. The resizing is handled entirely within the guts of the browser. It's outside the scope of the JavaScript world.

Now consider what happens when you are working with a large post where you can start to scroll the image outside the region of the editor. A well behaved user interface would ensure that the resize handles are not drawn outside of the the editing area.

I wound up noticing that with Internet Explorer 7, the image resize squares continue to exist outside the editor area. Moreover, the area belonging to the image's rectangle will prevent user interface elements from getting click events.

demonstration of resize handles outside viewport

As you can see with the image on the right, the resize handles are drawn on the top row of toolbar elements.

In this state, I coldn't click any of the buttons that fell within the image's rectangle. Want to click on the insert hyperlink button? Sorry, you'll have to scroll the content so that the rectangle is out of the way.

We were able to reproduce this problem also using the demo of FCKEditor, the editor toolkit upon which our editor is based.

It turns out that this is a problem with Internet explorer. In the fall of last year, someone reported this anomalous behavior exists in IE version 6 through 8 beta 2. If that is the case, then it looks like might plague users for some time to come.

Since the issue is in the native code that provides in-place editing for HTML elements, there is little, if anything that web developers can do to work around the issue.

Comments for The Trials and Tribulations of WYSIWYG Editors

Thursday, February 19, 2009 by Douglas Karr:: Aren't the new breed of "edit in place" editors avoiding INPUT and ELEMENT altogether through editable divs? As for images, I think too much control may be a hinder. Auto-placement with CSS and auto-resize (perhaps with some sizing and positioning options) are quicker to integrate and a company can ensure brand consistency. One example may be pre-programmed layouts before the editor (something like ExactTarget's content areas).
Friday, February 20, 2009 by P.J. Hinton:: @Doug: You are correct in the sense that modern rich text editors don't rely on traditional HTML form elements, but the ability to make a div element editable requires some black magic that is not part of the W3C HTML 4.01 spec. With both IE and Firefox, you can do this via a couple of approaches. One is to use JavaScript to set a document object's designMode to be 'On'. This is usually done when the editable item is an HTML iframe. The other is to add the attribute contentEditable='true' to the element where editing will be allowed. Once you do this, things like resizing of images can be done in place without any additional code. It's handled by the browser's internals (see bullet list of hyperlinks in my post). My post was discussing how a glitch specific to IE can adversely affect the usability of a rich text editor that leverages this technology.