Don't Get A Complex Over HTML

In the last rant, I waxed eloquent about the trend toward complexity in the HTML standard. In keeping with the high standards of the Internet, this was presented as a CONSPIRACY THEORY, which it probably really isn't (except by happenstance). But my main theme is that writing HTML isn't really that difficult and there are plenty of FREE TOOLS that can help you KEEP IT SIMPLE.

One common misconception is that AUTOMATION MAKES THINGS EASIER. This isn't always the case. In this article, I'm going to put several "automated" HTML generators head-to-head with plain old hand-made HTML. There may be a few surprises here, and as I get my hands on some other HTML editors, I'll come back and modify the comparisons as may be necessary.

Declare Independence From Complexity

Let's start with a very simple web page, one that's primarily text. To avoid any potential copyright issues, I picked the Declaration of Independence for the text. God Bless America! Does that bother you? Okay, GOD BLESS AMERICA!

Next, let's make it a little prettier, because we can't improve on the content. Here are the formatting guidelines that were used for each trial:

• A JPEG image of the original document was left-aligned at the top of the page.
• The title was set as a level 1 heading, centered with Arial/Helvetica/sans-serif font.
• The first line was set bold in default proportional font.
• All text was formatted with Arial/Helvetica/sans-serif.
• All text was colored brown, and the page background was colored light yellow.

This is what it looks like. Remember, this is a demo/test page & not supposed to be fancy. (Use the Back button in your browser to return to this essay after admiring one of the greatest political documents ever written!)

For these initial tests, I used four methods to generate HTML pages. First, the page was written manually using a FREE text editor (Pc Editor 2.51) with no code snippets or automation of any type. Second, I used Microsoft FrontPage 2000 to layout the same page. This took just a little longer, because FrontPage seemed to know more about where the image needed to be than I did. Third, I used Netscape Composer 4.79. And finally, I simply used the "save as HTML" function in Microsoft Word 2000 to create the page.

The HTML files were compared on the basis of file size and the number of errors generated when the code was checked using the W3C HTML Validator. This may have been a tad unfair to FrontPage and Composer, since theoretically they predate the current standard that the validator uses. I believe this triggered the FATAL ERROR for FrontPage (noted in the table below), but the fatal error for Composer was incorrect capitalization in the initial DOCTYPE declaration line.

And With All Precincts Reporting, The Results Are...

The Envelope, Please

Of course, you new who the LUCKY WINNER would be, didn't you? The CHEAPEST and SIMPLEST tool won out. The hand-made HTML yielded the smallest file and the fastest clean validation. I used a small inline STYLE SHEET to define the fonts as attibutes of the <P> class. The paragraphs are properly separated with <P> tags.

Microsoft FrontPage gave the second-best results. One interesting point: the font was set only to Arial. I'm sure there's a way to specify an alternate non-Windows font, but I was already at wit's end trying to get it to quit moving the image around. Also, FrontPage used a <BR><BR> construct instead of <P> breaks to put the blank lines between paragraphs in the body of the document. While this validated "clean", it is UGLY CODE. But it allowed FrontPage to define the font face only once for the main section.

The main reason for the "bulkiness" of the Composer HTML is that it used proper <P> tags in the main part of the document. But being style sheet "ignorant", Composer had to put a font face definition within each paragraph. There were also some strange empty paragraphs in the code.

Finally, Microsoft Word isn't really an HTML editor at all (unless you save as plain text and write the markups yourself). But it's a very fast way to build a web page from an existing document, and lots of folks use it. Heck, I use the "save as HTML" feature in Microsoft Excel when I need to kludge a fast web page from a spreadsheet that I've already invested a lot of time into developing. To be honest, though, Word didn't generate a true HTML page but rather an XML file, according to the Validator. The great bulk of this file is its extensive inline style sheet, which is very Microsoft-centric. In this case, the document had TOO MUCH STYLE

Fire Up That Text Editor

Even if you choose to spend BIG BUCKS on a tool like FrontPage, you're probably going to need to edit the final product to get it to validate. Okay, so 99% of the sites on the web aren't validated. That's no excuse. Both FrontPage and Composer required that I go in an manually edit the very first line (the DOCTYPE) to get the Validator to accept them. And a text editor with line numbering is the very best way to do it.

Bear in mind, too, that if you use the ADVANCED FEATURES of a program like FrontPage, there are likely going to be CROSS-PLATFORM COMPATIBILITY problems. Simply put, Microsoft doesn't want you to use a web browser other than Internet Explorer, and there are ways to make that happen. Also, really using FrontPage means having FrontPage Extensions on your server. Most web hosts provide that functionality nowadays. But there are SECURITY ISSUES with FrontPage Extensions -- especially when running on a Microsoft server platform. So don't think using FrontPage will relieve you from learning a lot of things. You'll just have to learn different things!

Whatever tools you choose to use, learn to use them correctly, and learn to write good HTML. Validate your work. Remember, LEARNING IS GOOD FOR YOUR BRAIN. Or as the Jefferson Airplane used to sing, FEED YOUR HEAD.

djeaux
04 September 2002

P.S. I do plan to add Dreamweaver, Coffee Cup, and newer flavors of FrontPage and Composer to this comparison later on. Check back soon!