Mozile: What You See is What You Editby Conor Dowling
"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.
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
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
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.
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
user-modify. It had values like
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
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
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
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.
Conor Dowling develops web sites for a living, and has also developed an avid interest in Mozilla applications.
Return to the Mozilla DevCenter.