HTML Editors vs. WYSIWYG Web Authoring Tools (article from Allaire site)

aloha, y'all!

thought y'all might be interested in the following, which is from our
gracious host's web site...  won't give the direct URI, because it is (a)
insanely long, and (b) probably invalid, since the site is run on cold
fusion, which imbeds verification information in the URIs that are passed
to the server (well, not quite, but that's a good enough thumbsketch), in
order to provide tailored content...  i found this linked from the HomeSite
4.0 page, which is relatively easy to find from allaire's front page, which
is located at:
	<http://www2.allaire.com/>
-- that's w w w the number two for any other speech users out there -- and
even easier to find using the following URI:
	<http://www2.allaire.com/Products/HomeSite>
note: the "p" in "Products" and the "h" and "s" in "HomeSite" are
capitalized -- when the page loads, search for the term "street"

note, too,  that i said "relatively easy" -- that is if you are using what
i'm using, which is MSIE 4.01SP2 with JFW 3.30.26...  but, in order to get
to this article from allaire's front page (which is where i started my
inquiry), using lynx, one needs to make several inspired leaps of faith in
order to jump through the right hoops...  so, for all of you lynx users out
there who really, really want to view the article in hypertext, you can
either find it using the HomeSite URI
<http://ww.allaire.com/Products/HomeSite> or, if you're really lazy, like
me, via the temporary copy i put at:
	<http://www.hicom.net/~oedipus/temp/allaire_street.html>

one quick observation: while the article makes a lot of sense, and clearly
shows that they are prime candidates for the AUGL -- it references, and
even links to, the HTML4 spec -- there is one glaring omission:
accessibility...   judging from their web site, there apparently isn't much
awareness about accessibility issues at allaire...  a search of the site
for the term accessibility, conducted via the internal search facility
located at:
	<http://www2.allaire.com/Search>
yielded 4 hits, but none of them actually pertaining to accessibility (in
fact, as far as i could tell, the only reason i pulled up 3 of those 4 docs
was that they contained the word "access", as in the legal disclaimer, "no
internet access necessary", contained in a sweepstakes registration form)

searching for "Web Accessibility Initiative" (with and without quotes),
"WAI", and "handicap" yielded no results, but a search for the term
"disability" did turn up a link to a rather old ZDNet story, archived at
allaire's site on 19 April 1999 by Maria Seminerio, entitled " 'Handicapped
access' hits the Web"

anyway, let me shut up and robert crooks speak -- i've got an eval to
download and install!
	gregory.

-- begin article
Street Level: Editors vs. Authoring Tools
by Robert Crooks

HTML Editors vs. WYSIWYG Web Authoring Tools

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.

With all these reasons, is there any reason not to uninstall your WYSIWYG 
authoring tool? Sure. It doesn't have to be either/or. 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 
pleasanter 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. Please
direct 
comments on this column to talkback@allaire.com

Copyright © 1995-99 Allaire Corp., All rights reserved.

-- end article
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <oedipus@hicom.net>
   President, WebMaster, & Minister of Propaganda, 
        VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
--------------------------------------------------------

Received on Thursday, 26 August 1999 03:00:09 UTC