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:
- 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 very uniform across all the pages, and to be sure of
that you need to know what code is being written.
- 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.
- 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 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.)
- 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.
- WYSIWY(NT)G: (what you see is 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 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.
- 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.
