Rich text editing is becoming an essential part of Web 2.0 applications that deal with user-generated content, publishing and collaboration. While text editing is built into modern browsers, harnessing it into a stable usable application isn’t always as simple as it should be. Managing cross-browser compatibility, document formats and integration with other components is critical to a successful implementation.
The good news is that in most cases you can use ready-made components for this capability. Even so, it is good to have an understanding of the fundamentals of text editing. In some very special instances there’s a case to be made for building your own.
Text editing comes in two flavors. There’s basic text editing built into all modern browsers and there are also a variety of plug-ins using Java, Flash, and ActiveX. Generally speaking, only applications that need very sophisticated text editing will use plug-in technology.
Text editing was introduced by Microsoft in 1999 as part of Internet Explorer 5.0 and was immediately put to good use in its newly acquired Hotmail. With the success of Hotmail and other applications such as Yahoo’s Web site builder, Mozilla implemented the capability in 2002 and called it MIDAS. As of 2006, all the major browsers including Opera and Safari had built-in editing.
The essence of rich text editing is to set the designMode attribute of the document to ‘on’. This must be done via JavaScript. Once it is on, the entire document is editable and responds to the usual mouse and keyboard editing conventions. In practice, you use an iFrame so only a single region in the application is editable.
This is the minimal code needed to make that happen:
<HTML>
<BODY onload=startEdit()>
<IFRAME NAME=myEditor ID=myEditor>
<SCRIPT>
var doc;
function startEdit() {
doc = frames[ÔmyEditor'].document;
doc.designMode = “On”;
setTimeout(”doc.body.innerHTML = ÔLook Ma I can Edit’;”, 0);
}
</SCRIPT>
</BODY>
</HTML>
This code starts with an iFrame and sets the design mode attribute to ‘on’. It then puts text in the iFrame that can be edited. The setTimeout addresses a quirk in Explorer that makes you wait until the event completes before putting text into a document that’s just been put in design mode.
Adding all of the editing controls is really straightforward using execCommand:
<input type=button value=”Bold” onclick=”doc.execCommand(ÔBold’);”>
The execCommand is a member function of the document object and the Range object. It takes an argument that specifies the formatting or editing to be done and then carries out that operation on either the currently selected text or at the cursor. For example, the Bold command above will either bold the currently selected text or else set up the editor so subsequent characters typed in will be in bold. There are commands for every conceivable text-editing task.
The execCommand has a counterpart called queryCommand that gives you information on the current formatting. It can be used to set the visual state of your editing control. For example, you might want to implement bold as a graphical button that appears depressed when the current selection or cursor is bold.
The whole idea behind the Microsoft design is that you can implement a full-fledged rich text editor in a few hundred lines of JavaScript. But it has some limitations. Although you use the term rich text editing, what you’re really dealing with is everything in the HTML spec. The user can paste anything at all into the editor and your application on the back-end must deal with it.
Your editing space is a fixed size bounded by the iFrame. Unlike other HTML elements an iFrame can only scroll and so your editable portion can’t flow within the outer frame.
Everything in the iFrame is editable, which means that if you plan on including any sort of complex objects in the editable area that might be wrapped in HTML then the wrapping itself will be editable and could be inadvertently changed.
Microsoft addressed some of these limitations in version 5.5 of Internet Explorer by allowing a contentEditable attribute on DIV elements so they can become editable. A DIV will grow and flow within the context of a document. Mozilla also improved on a few things in its implementation by making the Selection and Range object based on real DOM nodes.
english
español
Deutsch
français
Italiano
Português
русский
Loading ...
Leave a reply