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.

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.