Print

Mozile: What You See is What You Edit

by Conor Dowling
10/03/2003

"The intuitive editing interfaces that would make authoring a natural part of daily life ... are still maturing." -- Tim Berners-Lee in "Spinning the Semantic Web"

Today, developers compose most of the Web in stand-alone web editing applications or in simple text editors. Modern browsers render, but they don't allow users to edit what they see. There is no fundamental reason for this gulf between editing and viewing. After all, the Web is about interaction, not dumb page flipping, so you should be able to hit "edit" in your favorite browser and manipulate content as easily as you view it, WYSIWYG-style. Mozile, which stands for Mozilla Inline Editor, is a new Mozilla plug-in for in-browser editing. This article provides an overview of Mozile and what in-browser editing means today.

In-Browser Editing

A browser that supports editing should address three requirements:

  • Edit XHTML: Editing HTML today means sticking to the rules of XHTML, the new revision of HTML that makes it a flavor of XML.

  • Precise scope: You can edit all or only parts of a page, and you can edit using any valid XHTML construct or only a particular subset of XHTML and CSS styles.

  • Publish to any CMS: Today, content publication is usually under the control of a content management system. This server-resident application decides who can view and change content. It is the CMS that would offer appropriate editing options to a user and accept changes posted back to it.

Mozile addresses all three in-browser editing requirements.

eDOM: Enhanced DOM for Editing

Composer, an HTML editor, is one of the applications in the Mozilla Application Suite. It is, like most web editors, distinct from the browser. Mozile takes a different approach. As a browser extension, it adds XHTML editing functionality to the Mozilla browser itself.

The starting point for Mozile is Mozilla's DOM, which is mainly a straightforward implementation of the standard W3C DOM. However, like the standard DOM, it lacks macros to style and reformat text according to the rules of XHTML. The first part of Mozile, eDOM (or editor DOM), enhances the standard DOM to make it easy to build a variety of editing interfaces.

For example, as XML, XHTML bans overlapping tags. If you wish to apply inline style to a piece of text, you use the span element with a specific style setting. It is important not to create overlapping spans and to create the minimum number of them. Mozile adds the styleText method to the DOM's Range object so that any Range of text can take a valid style using the minimum number of non-overlapping span elements.

By enhancing the DOM with the set of editing methods needed for everything from list management to inserting pasted content in an XHTML-conformant fashion, Mozile's eDOM provides the foundation for in-browser editing within Mozilla.

Context-Sensitive Editing

In all but the simplest cases, XHTML editing means being able to change only certain parts of a document in particular ways. In effect, it is more important for an editor to enforce certain restrictions than it is to allow arbitrary editing of every part of a document. For example, a user may not be allowed to edit the fixed or template parts of a page, like a copyright notice or a banner. He may be allowed to change the title of a document, but may not change its style. However, the main body of the document may be edited in any way the user sees fit, or perhaps no inline styling is permitted, but the user can choose from a range of paragraph styles. In other words, being allowed to edit is not black and white -- there is a range of editing options.

Let's start with whether a section of a page is editable or not. Some time ago, in the last millennium, some folks at the W3C invented a new CSS property called user-modify. It had values like read-only and read-write to define whether an element of a document should be editable or not. This property was added to Mozilla as moz-user-modify and then left without an implementation. Mozile provides an implementation.

With Mozile, you can make any element of a page editable by setting its moz-user-modify CSS property to read-write. This establishes a self-contained editing context: by default, a user can change any of the content of that element, but editing ends if he selects outside of that element. Using moz-user-modify, certain areas of a page -- its title and the main content area, for instance -- can be marked as editable, while other areas -- a sidebar or copyright notice, for example -- can be marked as read-only. Like all CSS, this property separates editing markup from the document itself. Different CSS can be fed to different users, depending on their capabilities and permissions. Feeding a read-only stylesheet with a document prevents any editing by a user, while feeding one with moz-user-modify set to read-write allows editing.

So Mozile's eDOM supports any valid XHTML editing operation, and its implementation of moz-user-modify allows you to specify whether an element is editable or not. Something is missing, though -- Mozile needs to allow you to specify precisely the range of editing actions possible for each editable area. This is a new area for Mozile, and a number of approaches are being tried. One approach is to use XBL to specify keyboard handling and a toolbar for different scenarios -- one XBL binding would cover text-only editing, another would allow certain inline and block-level elements but no inline styling, and, of course, there would be an "anything goes" binding. CSS can attach the appropriate binding to each editable element so in addition to specifying moz-user-modify for an element, you would also define a binding that determines the range of modifications supported. I suspect that this is an area where a number of mechanisms will be provided, some more powerful and some easier to use than others.

Publishing to Your Favorite CMS

Today publishing to the Web usually means posting changes to a remote content management system (CMS). The CMS is responsible for granting editing permission to a user and for accepting valid changes from a user. Here Mozile is relying on code contributed from Bitflux, an ambitious, fully functional XML-based CMS that will use Mozile for basic text editing. For user interaction, Bitflux uses WebDAV, an enhancement to HTTP that allows a remote user to securely get, lock, and change remote files on a web server. WebDAV is supported in Apache and there are a number of client-side libraries for browsers. Of course, your CMS may use a different protocol, and again, thanks to Bitflux, Mozile has a plug-in "transport" architecture that lets a CMS provider add new posting methods.

Resources

Mozile is being developed as an open source project hosted on mozdev.org. For more information and to download Mozile, go to mozile.mozdev.org.

Conor Dowling develops web sites for a living, and has also developed an avid interest in Mozilla applications.

Return to the Mozilla DevCenter.