HTML Editors vs. Authoring Tools

by Robert Crooks

Flash MX Training Solutions Find the books, videos, and CD-ROMS to get the most from Flash MX! Flash 5 Training Solutions Find the books, videos, and CD-ROMS to get the most from Flash 5! Production Ready Digital Artwork Smart Designer, CoCUT, EuroVECTOR, Logos, Templates, Clipart and more! Web Books Designing Web Graphics 3 HTML & XHTML: The Definitive Guide Dynamic HTML: The Definitive Reference HTML 4 Training Solutions Dynamic HTML Training Solutions

Anyone who has taught HTML and Web development has heard the question: "Why bother learning all these tags and attributes if you can use a WYSIWYG editor?"

It's a fair question, so we asked some Web developers who hand-code HTML why they do it. Here are some reasons we heard:

1. Control:

A text-based HTML editor shows you exactly which tags and attributes you are using and how. That gives you more control over the document. For instance, in a WYSIWYG editor, say that you press Enter a couple times to start a new paragraph: did the editor insert two <BR> tags, or one <P> tag? Or let's say that you select the contents of a table cell, and then click an icon that centers it. You might have "written" any of the following code:

<td align="center">...</td>
<p align="center">...</p>
<center>...</center>
<div align="center">...</div>


In order to know which code was written, you would have to view the source. Do you care? Well, if the rendered page looks the way you want it to, perhaps not. But there are three reasons why many developers do:

• Every browser does not support every tag and attribute, and there are times when you need to be sure that you're using the ones that are most widely supported.
• The exact layout you want often requires fine-tuning the attribute values for tags, such as the horizontal and vertical space around images.
• When existing site designs are updated, the most efficient way to make modifications is through some kind of extended replace function, rather than editing every page individually; but extended replace works well only if the HTML coding is very uniform across all the pages, and to be sure of that you need to know what code is being written.
  
  
2. More efficient code:

Pages created in a WYSIWYG mode tend to be "heavier" than equivalent pages created through hand-coding, for several reasons. First, when you select text to move or delete it, the editor has to decide whether you're trying to select only the text, or also surrounding tags. If it guesses wrong, the chances are that you will recreate the tags left behind in the new location, and leave the old empty tags intact, as long as the pages looks right.

Second, if you decide you don't like a formatting effect you've already applied (such as increasing the font size), rather than figuring out how to remove the offending tag, you may find it easier to apply to opposite effect (make the text smaller) on top of the first one. Now you have two tags working together to do nothing.

Third -- this one is especially severe if you use a WYSIWYG authoring tool to convert a word processing document to HTML -- WYSIWYG editors sometimes write a lot of code in the form of multiple nested lists or table cells and rows without contents to produce exact horizontal spacing of contents.

3. WYSIWYG authoring tools tend to favor physical formatting over document structure:

A quick look at the toolbar of most programs confirms this. The most prominent icons are usually for adjusting font properties, bolding, italicizing, indenting, or centering text -- in short, the most familiar icons from a word processor toolbar. (Which are not so good for word processing either, where users should probably be using Styles instead of these icons, but that's another matter....) Ways to apply various heading tags, or create table headings, or create blockquotes are usually much less obvious. In some cases you have to dig deep into menus to find a way to insert block or logical tags. This makes sense from the standpoint of using WYSIWYG to "protect" developers from the intricacies of HTML, but not from the perspective of the way HTML is supposed work.

Using HTML to design the physical appearance of documents has always been contrary to spirit of HTML, which is intended to be used as an information structuring language like SGML. In the HTML 4.0 specification, the World Wide Web Consortium has make this explicit: HTML should be used for information structuring, and physical appearance should be specified in style sheets. The physical formatting tags such as <FONT>, <U>, <STRIKE>, and <CENTER> are now officially deprecated (see http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.3.5).

This isn't just a matter of HTML purists flogging the honest practitioners: minimizing or eliminating physical formatting makes HTML documents simpler, less prone to syntax errors, and simpler to maintain. (Structure and physical formatting are rigorously separated in both SGML and XML.)

4. Flexibility:

Aside from the issue of document structure vs. physical formatting, WYSIWYG editors tend to make a few tags easily accessible, while entering others is difficult at best. In some cases there is no way to enter particular tags except to switch to a plain HTML code view and type them in. Text-based HTML editors generally provide easy ways to insert any tag or attribute.

5. WYSIWY(NT)G: (what you see is what you [not they] get).

Site developers can never be reminded too often: no two browsers (or browser versions) process HTML code in exactly the same way. In some cases you can use such basic HTML so that the rendering will be acceptable in any browser, but in most cases you have to find some workarounds to handle browser differences. HTML editors don't insure good cross-browser code, of course, but they generally make it easier to insert the particular tags and attributes you need. More importantly, since you are looking at the tags and choosing them, it's less likely that you will choose a tag or attribute that may cause trouble in certain browsers.

6. Speed

The WYSIWYG view comes at a cost in system resources. Each time you press a key, the program must reinterpret and redisplay the page contents. Depending on the efficiency of the authoring program, the length and complexity of the page, the amount of graphics that are included, and how robust the system is, the time required to refresh the display may be significant. There are enough variables here that you may never notice the delay with a particular authoring program on a particular system, but a well written text-based editor will always be faster than a WYSIWYG authoring tool.

With all these reasons, is there any reason not to uninstall your WYSIWYG authoring tool? Sure. It doesn't have to be an either/or decision. HTML authoring is partly HTML coding and partly data-entry. We think a text-based HTML editor like HomeSite is superior for the coding part, but a WYSIWYG interface is often more pleasant to use when typing in the page contents, and may be easier to use for specialized purposes such as modifying table design. But if we had to choose one or the other ... well, you can guess.

-Robert

Robert Crooks is an Allaire Certified Instructor at Allaire Corp., and a regular contributor to the Allaire DevCenter. Please direct comments on this column to talkback@allaire.com.

_{Last Updated November 14, 1998.}

Press the Subscribe button at right to receive our free CorelDRAW Unleashed emagazine! Each issue is full of top notch tutorials from the leading CorelDRAW experts worldwide. It will definitely increase your productivity.

Get magazine details!

CorelDRAW X3 Unleashed

Get Conference details! Get CorelDRAW Unleashed Boot Camp details!