Related Links
The WYSIWYG ListThe Universal Canvas
Mozilla Editor
Microsoft How To
MS DHTML Editing
New MSHTML Editing
The WYSIWYG Report provides detailed comparisons of available WYSIWYG technologies and products to help you decide the best approach for your content or knowledge management strategy. Commonly known as WYSIWYG widgets, these in-browser tools are essential to Content Management System developers who want to provide their users with the simplest possible interface for editing server-side assets through a web browser.
The WYSIWYG Report chronicles efforts to add ("what you see is what you get") visual editing functionality to web browsers. Years from now, when we do word processing, spreadsheets, presentations, databases and all our familiar desktop office applications over the web, it will be because browsers allow us to work over the web as conveniently as our desktop applications do today.
Whether this comes about because Microsoft's .NET or Sun's JavaONE technology lets us rent the same Office applications we know today as "web services" , or someone else writes open-source and really free equivalents that cost organizations very little (because there is no per-user software charge) remains to be seen. In either case, we need more powerful visual editing capabilities in the browser.
Tim Berners-Lee, the inventor of the world wide web (and now Director of the World Wide Web Consortium - the W3C), recalls that his original design was for pages that could be immediately edited in the browser. For him, HTML (hypertext markup language) was a stopgap tool to get material visible on the web. Ten years on, and we are still years from immediate visual editability. Ward Cunningham's WikiWikiWeb does come close to Berners-Lee's "edit this page" vision.
Microsoft's MSHTML Active-X Controls, first introduced with Internet Explorer 4.01, have dominated the field of WYSIWYG editing widgets, although they have limited CMS visual editing to clients on the Windows platform. Several software development groups have enhanced the Microsoft widgets, offering technical support for incorporating them into a CMS, and in some cases offering easily customized versions. Ephox has a "configurator" that lets the CMS OEM turn on just the tools desired in the WYSIWYG interface.
Until recently, cross-platform WYSIWYG visual editing in the browser has only been available from Java-based solutions, most of them closed, proprietary, and expensive. The leading Java visual editing widget is from Real Objects. The one Java open-source WYSIWYG editor is not yet ready for prime time, and commercial Java applet and application solutions seem to lack the full features of the Microsoft Active-X Controls.
Java, with its write once, run anywhere philosophy, seems like the ideal solution for cross-platform, cross-browser visual editing tools. The reasons behind its relative poor performance are traceable to problems inherent in the browsers themselves, problems that cause the same web page to look different in different browsers. We will look at the three aspects of this problem in some detail.
Now cross-platform WYSIWYG editing is possible using the Mozilla 1.1 browser (for Windows, Mac, Linux, Sun, etc.), which leverages the Composer visual editing long familiar to Netscape browser users (since Navigator Gold in Netscape 3). There are several reasons why Mozilla (and future Netscape browsers as well as other "Gecko"-based browsers to come) will emerge as the preferred cross-platform solution. We will discuss these below. Bitflux and Xopus are XML WYSIWYG visual editors, and skyBuilders skyWriter is an HTML visual editor for the Mozilla browser.
Another cross-platform WYSIWYG solution comes from Ektron, the market leader of in-browser editing tools, who have applied Macromedia Flash technology to the problem. Their eWebEP is a Flash download that provides in-browser WYSIWYG visual editing as long as a modern Flash Player is installed in the browser. Like Java solutions, they will not have the benefit of the hundreds of man-years of browser development.
To make a web page from HTML code three distinct steps are involved, each done by tools with many man years of development behind them. These steps are:
Anyone who builds a WYSIWYG editor has to do all these steps as well or better than the browser designer, because they all are necessary. The easiest way to do this is to leverage the enormous investment made in the browser itself, and this is what the IE and Mozilla widgets do.
The HTML code parser has to scan the characters in an HTML file and decide first what are the tags (in angle brackets) and what is the content. If the HTML programmer uses bad syntax (like improperly nested tags) it has to decide what to do. Early strict parsers (mostly Netscape) just rejected these pages, but Internet Explorers often made a "best guess" as to the programmers intentions. This then encouraged web page authors to write poor code, and today's modern browsers have to be programmed to handle these exceptions or all the old web pages and badly written new ones will break. It's estimated that half the programming in a browser is now these exceptions.
We should assume that our knowledgeable CMS authors will write good HTML, and we could enforce the rules, but the fact remains that a WYSIWYG widget designer has to write all these parsing rules for a tool independent of the browser.
The output from the parser is a tree-structured document with a root, branches, and nodes that contain the web page content. Each browser has its own DOM. The W3C has a proposed standard DOM, not fully implemented in any browser except the W3C's own Amaya reference design.
Once the source of an HTML page is transformed into the DOM structure, the question arises how the DOM exports the edited structures back to a source text file. Does it preserve all the information in the original file, apart from any edited sections? This is called source preservation or the round-trip problem. As a web page designer, you may be unhappy to find your neatly indented and carefully capitalized code coming back without the indents and with everything in lower case. Even worse, if the parser misinterpreted or ignored some tags, your code may come back with different tags.
Pure XML editors like Bitflux and Xopus need parse only XML structures, and only after validation, which makes the parsing and source preservation problems much more tractable. Microsoft's new MSHTML control for IE6 loses all indenting on a round trip to the DOM and back.
The final step for the browser is converting the DOM structure into visible pixels on the computer screen and activate the screen to sense the mouse position, mouse clicks, and keyboard presses. These allow the user to interact with the document. Even if the browser manufacturers used identical DOM structures, Internet Explorer might render font sizes or table positioning one way and Netscape and Mozilla another. These rendering problems become hardware dependent (Mac vs. Linux vs. Windows).
This part of the problem will not go away until WYSIWYG (what you get) becomes WYSIWEG (what everyone gets).
In any case, the problem for the WYSIWYG visual editor is to build that rendering engine and UI. If they build it in the very powerful Java Advanced Windowing Toolkit, they may get something that looks quite different from either IE or Mozilla.
This explains why Java based WYWSIWYG visual editors are likely always to have poor performance compared to those leveraging the parsers, DOMs, and rendering engines built into the latest browsers. Perhaps the strongest evidence for the challenge to Java-based browsers is Sun's announcing the end of life in April, 2003 for HotJava, the original Java browser from the creator of Java technology.
These three problems are not specific to visual editors in the browser. Desktop HTML editors like Front Page, Dreamweaver, and HomeSite have the same problems. HomeSite solves this by building Microsoft's IE browser into their code. Microsoft has long offered developers the browser as a kind of super Active-X control, with liberal royalty-free licensing. Needless to say, most of the desktop editors have had more financial resources behind them than the typical in-browser WYSIWYG editor project.
The very latest development is from the Mozilla Organization, whose 1.1 release exposes elements of their Composer WYSIWYG editor architecture in their XML User-interface Language (XUL).
How to build a XUL application is spelled out in the new O'Reilly publication Creating Applications with Mozilla, in the XUL Reference pages at mozilla.org, and can be gleaned from open-source code in various efforts to build Mozilla-based WYSIWYG editors, notably Eric Hodel's ComposIte and the skyWriters released by wysiwyg.skybuilders.com.
Links to Some WYSIWYG Visual Editors
| Product | Technology | Website |
|---|---|---|
| The List of TTW WYSIWYG Editors (Paul Browning) | All | The List |
| Bitflux (XML Editor) | Mozilla | Bitflux |
| ComposIte | Mozilla | composite.mozdev.org |
| Ektron eWebEditPro | IE | www.ektron.com |
| Ektron eWebWP | Flash | www.ektron.com |
| Ephox Edit-Live and Edit Live for Java | IE and Java | www.ephox.com |
| Hexidec Ekit | Java | www.hexidec.com |
| Jspell | Java | www.jspell.com |
| Real Objects GmbH | Java | www.realobjects.de |
| skyBuilders skyWriters | IE and Mozilla | wysiwyg.skybuilders.com |
| WebsiteASP OmniUpdate | IE | www.omniupdate.com |
| Xopus (XML Editor) | Mozilla | www.xopus.org |
Some Newsgroups that discuss WYSIWYG Visual Editors
|
alt.html
alt.html.editors.enhanced-html alt.html.editors.webedit alt.html.webedit |
| alt.www.webmaster |
|
comp.infosystems.www.authoring.html
comp.infosystems.www.authoring.site-design comp.infosystems.www.authoring.tools |
|
comp.lang.java
comp.lang.java.programmer |
| comp.lang.javascript |
|
comp.os.linux
comp.os.linux.misc |
| comp.publish.electronic.end-user |
| comp.sys.mac.apps |
|
microsoft.public.inetsdk.html-authoring
microsoft.public.inetsdk.programming.dhtml_editing |
| microsoft.public.mac.explorer |
| microsoft.public.windows.inetexplorer.ie5.programming.dhtml.scriptlets |
| misc.writing |
| netscape.public.mozilla.wishlist |
| php.general |
Related Links
