Browser Based Text Editors
Extracted from http://web2.sys-con.com/read/529444_1.htm
Overview
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's 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. We'll cover the basic details of how browser-based text editing is done in both Internet Explorer and Firefox and discuss the best way to approach implementing this capability in an application.
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.
The Built-in Editor
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's 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></IFRAME>
<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');">
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.
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. This makes things quite easy as long as you're willing to hand everything off to the editor and accept these limitations:
Although we use the term rich text editing what we'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.
It's difficult to mix your own editing with what's done by the built-in editor. This is because with Internet Explorer there's no way to determine which DOM nodes have been selected and so you can only deal with the source HTML of the selection.
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. Unfortunately, Microsoft didn't adopt the Mozilla way of doing things and Mozilla never implemented contentEditable. So for all practical purposes a very limited subset of the functionality is possible for cross-browser applications.
Editors Based on the Built-in Editors
There are a great number of editors based on the browsers' built-in editing capability. The Area site is a good place to start looking since it lists 94 different packages, many of which are open source. Some of the more popular open source ones are:
FCKEditor (www.fckeditor.com is one of the more mature editors that has overcome many of the limitations of browser-based editors. The editor has had over two million downloads and a license is available under the LGPL.
RTE (Forked) http://rtef.info is one of the original rich text editors available under the MIT license.
For more modest needs, Yahoo http://developer.yahoo.com makes a rich text editor available under the BSD license.
Some things to consider when choosing an editor:
How much functionality is really needed? Choosing one with too many features makes for large applications that could confuse users. How well will the editor integrate with the rest of the application. Some are much more configurable and have richer APIs than others.
Select an editor with a strong community around it if you're going the open source route or an established company if you're buying a license. A case in point is that one of the first popular editors called HTMLArea is now discontinued.
Make sure the editor's footprint is suitable. Some of these editors are really big and make for long application load times.
Plug-in Technologies
Given the limitations of the built-in editor, a number of companies have created more sophisticated products based on Flash, Java, and ActiveX. Flash and Java also have compatibility across a wide range of browsers. The catch is that the user may have to install the plug-in. With Flash this generally isn't a problem; the penetration rate is quite high except for the very latest version. Java is somewhat lower.
Applications that really need to emulate Office products often use Flash and Java. Examples of Office alternatives include the Java-based ThinkFree (http://thinkfree.com) and Flash-based (www.virtub.com) Buzzword.
There are a number of plug-in-based editors that can be licensed and the htmlArea site is a good place to start. So far all require commercial licenses. One of the more mature editors is made by RealObjects (www.realobjects.com).
Some things to be aware of when choosing plug-in-based editors are:
* How well will they integrate with your application? Unlike open source editors, you won't be able to add integration points. In general, integrating plug-ins is less flexible than integrating JavaScript-based editors. * Make sure that the penetration level of the plug-in technology is suitable for your audience. * With Java, be aware that many features require "signed applets." * Check the size of the editor.
Integration Issues
Assuming that your application manages the data, the rich text-editing component must integrate with your application in several ways:
* Getting data from the server to the editor * Getting data from the editor back to the server * Handling of images
Depending on the editor component the integration may occur at the client or server level. It will usually be easier if it can occur at the client level as this gives you more flexibility in your server architecture. Data can then be transferred back and forth to the server using whatever method your application currently uses. The more sophisticated editors, however, tend to integrate at the server level.
If the editor is to allow users to upload images and include them in rich text this introduces additional complexity. Images must be uploaded before the editor can use them. So this integration is usually handled at the server level. If you want to customize how images are handled, make sure that the editor you choose has a very flexible image integration capability.
Putting It All Together
There are three options for implementing rich text editing in an application:
* License or buy an existing editor * Modify an existing editor to suit your needs * Develop your own
Developing your own editor would only make sense for very modest needs where the plain vanilla features of designMode would suffice. The other case would be for very complex needs that aren't covered by an existing package.
Using an existing editor is clearly the most sensible option. Using one out-of-the box without having to modify is preferable. Writing an editor that's as feature rich as the ones that exist today is a very difficult process that requires expertise in JavaScript, DOM, and the many quirks of modern browsers. These editors are often a minefield of logic that use different techniques to do the same thing with different browsers. In fact, some of them have completely different sources for Internet Explorer and Mozilla-based browsers.
Modifying an existing open source editor is an attractive option. Our own experience suggests that it's unwise to go too far in trying to modify an existing editor; much of its value from the existing editor will be lost because it will be difficult to keep up with the changes.
How We Chose a Solution
Our site builder called siteZen http://sitemagix.com was first developed in 2002. At that time the target browsers were Netscape 4.7 and Internet Explorer 4.0. The only realistic option for text editing was plug-in technology and we chose the Java-based editor from realObjects. We found that application load time was an issue and the deep level of integration that we wanted to achieve wasn't possible.
As Internet Explorer became the dominant browser in 2003 we decided to use the open source RTE editor. Because we had very specific editing requirements that were above and beyond RTE we decided to modify it heavily. Half way through the project we realized that it made more sense to start from scratch and so we implemented our own editor based on Microsoft's contentEditable. This gave us the all-important feature of having several regions that the user could edit that would all flow together.
As Firefox gained market share and Apple introduced Safari supporting only Internet Explorer was no longer viable. Since Firefox didn't support the contentEditiable feature, we embarked on an ambitious project to write an editor that didn't use any of the built-in editing features. All editing is done through JavaScript directly manipulating the DOM. While this was previously thought to be impossible because of speed or stability concerns, we found ways to make it fast enough and found that stability was actually improved by staying away from the proprietary built-in editing features. A demo can be seen here http://urte.sitemagix.com/_mgxroot/urte.html.
While this isn't a recommended solution for most companies it's discussed to illustrate how there are always other alternatives if you try hard enough.
Closing Thoughts The key to implementing rich text editing is to match your requirements carefully against the available solutions. Picking the wrong solution can cause a lot of headaches. Once you pick the right solution you should do your own cross-browser testing to make sure that the entire integrated application still works across the browsers you plan to support.
If you plan to do any of your own programming on the editor itself, make sure you have experience with DOM and allow a lot of extra time for the many quirks you're likely to run into. Finally, if you are waiting for new developments to emerge in the HTML space you may have to wait a while. HTML 5 will formalize some of the editing specifications but there's no silver bullet waiting in the wings.
All in all, implementing rich text editing is considerably easier than it was a few years ago and, with a little care, is quite manageable.