HTML Design:

The Dichotomy of Philosophy and Pragmatism

by Bob Clark

November 1998



HTML -- HyperText Markup Language -- is the driving force behind the popularity of the world wide web.

This document is directed towards someone who is familiar with HTML syntax, and aims to address some of the conflicts that arise between HTML philosophy and the pragmatic concerns of web page design.

Table of Contents:


HTML Syntax

We can skim over HTML tags and syntax quickly, as it's probably more valuable to explore HTML philosophy, techniques, gotchas, and tools.

To be honest, HTML syntax isn't really that difficult, and we'll just touch on some HTML syntax tools before moving on to the meat of this document.

There are a lot of HTML tutorials out there. I'm not going to waste any time building an HTML syntax tutorial when other people have already done the work way better than I could.

Everyone and their dog has HTML tutorials focusing on syntax and use of common tags. My favorite is the tutorial at HTMLementary.

HTMLementary is great stuff. You can jump to any topic you want and see both the HTML syntax and the resulting web page. It starts with the very basic document structure and briefly visits most common HTML tags.

These topics are covered in great detail at HTMLementary, but for now some high points include:

Once you're acquainted with some of the basic structural elements of HTML, the single best HTML learning tool is your browser's "View Source" command.

If you stumble onto a web site that looks really cool or professional, you can view source to see how the author did it.

HTML is kinda neat because you can't really hide it. Your browser needs the HTML code to generate the page. In fact, a common question in some of the HTML newsgroups is "How do I hide the HTML source." When it comes down to it, you can't.


HTML Philosophy

HTML is a document-markup language. It's designed to structure documents logically. The series of headers, unordered lists, ordered lists, and so forth all describe the structure of a document. They don't tell precisely how it looks -- only what it means in the context of the document.

The point is, HTML is not a WYSIWYG page-layout language. It's a document structure specifying language.

And this is typically a good thing. Most of the times I use HTML, I don't care about the pixel-by-pixel coordinates of each word. I care about where in the logical structure of the document something lies.

But let's go further, beyond the assumptions inherent in a text-on-screen paradigm. Browsers other than Netscape and Internet Explorer exist. Blind people can use text-to-speech technology.

What's a text-to-speech browser gonna do with <i>this</i>? Why not use <em>this</em> instead? They look the same on common browsers, but they specify the document structure better than the typeface tags do. But they give more specific information for a text-to-speech browser to interpret.

Font tags are often an indicator that you're misusing HTML, or at least pushing the envelope of good taste or wise design. Tags like <b>bold</b>, <i>italic</i>, <s>strike-through</s>, and <font size="4" color="ff0000">various font parameters</font> aren't really document descriptors. Things like <strong>strong emphasis</strong> and <em>emphasis</em> are document descriptors.


Pragmatic HTML Techniques

So now that we've discussed that HTML is not a page-layout language, how can we use it for page layout?

Actually, although we're trying to make pages pretty, we're still not telling each jot and tittle exactly which pixels to live at. We're suggesting -- hinting -- to our browser about how we basically want this document to look.

Tables can be used for page-layout purposes. Yes this stretches the HTML concept a bit, but judicial use of tables can make pages easier to read. Specifically, you can limit the width of text content so you don't get monstrous lines. Tables can also be convenient for "tab stops" to structure the appearance of your document.


GENERIC ETHNIC JOKE #2

A person belonging to an ethnic group whose members are commonly considered to have certain stereotypical mannerisms met another person belonging to a different ethnic group with a different set of imputed stereotypical mannerisms.

The first person acted in a manner consistent with the stereotypes associated with his ethnic group, and proceeded to make a remark that might be considered to establish conclusively his membership in that group, whereupon his companion proceeded to make a remark with a double meaning; the first of which could be interpreted to indicate his agreement with his companion, but the other meaning of which serves to corroborate his membership in his particular ethnic group.

The first person took offense at his remark and reacted in a stereotypical way!

If you put this text into a wide browser window, it can be kind of tough to read. The text reaches from one end of the monitor to the other, and it can be uncomfortable to track what line your eye is on.


 

GENERIC ETHNIC JOKE #2

A person belonging to an ethnic group whose members are commonly considered to have certain stereotypical mannerisms met another person belonging to a different ethnic group with a different set of imputed stereotypical mannerisms.

The first person acted in a manner consistent with the stereotypes associated with his ethnic group, and proceeded to make a remark that might be considered to establish conclusively his membership in that group, whereupon his companion proceeded to make a remark with a double meaning; the first of which could be interpreted to indicate his agreement with his companion, but the other meaning of which serves to corroborate his membership in his particular ethnic group.

The first person took offense at his remark and reacted in a stereotypical way!

 

Here's the same table, only with the "border" attribute set so we can see the structure of the table.

From now on, I'm going to leave in the visible table structure, just to clarify the discussion a bit.

 

GENERIC ETHNIC JOKE #2

A person belonging to an ethnic group whose members are commonly considered to have certain stereotypical mannerisms met another person belonging to a different ethnic group with a different set of imputed stereotypical mannerisms.

The first person acted in a manner consistent with the stereotypes associated with his ethnic group, and proceeded to make a remark that might be considered to establish conclusively his membership in that group, whereupon his companion proceeded to make a remark with a double meaning; the first of which could be interpreted to indicate his agreement with his companion, but the other meaning of which serves to corroborate his membership in his particular ethnic group.

The first person took offense at his remark and reacted in a stereotypical way!

 

But tables aren't a panacea. They can zap you when you're not paying attention.

Here are two tables. Each has identical parameters (including width attributes) but different contents.

  
This table cell has a lot more contents than the previous table's first cell. Each cell in this table was specified to have the same width as the corresponding call in the previous table. 

The practical upshot is that it appears on the surface that you can specify the width of table cells. Actually, though, it's more of a suggestion. "Please, browser, if you find it convenient, could you consider making the first cell around 200 pixels or so wide?" You're not gonna be able to specify anything more concretely than that.

In many cases, the reason you're doing this is for "tab stops" -- you want things in a document to line up with each other, and you don't care if it's off by a few pixels, as long as everything is internally consistent.

When you're doing this, avoid using lots of separate tables with handcrafted width parameters. Rather, use one table and use the colspan parameter to skip columns.


Here are a couple examples of trying to use tables to give an outline pretty formatting. Again, I've left the table structure visible only for clarification.

Here's the wrong way to do "tab stops" or an outline.

I. My Outline of How to Take Over the World
  A. America
    1. Increase uncertainty and paranoia
      a. encourage speculation about UFOs, black helicopters, and UN plans to invade the US
      b. enlist Art Bell as my evangelist
  B. Europe
    1. Leverage distaste for Americans
    2. Apply bizarre French awe of Jerry Lewis to my nefarious advantage
  C. Australia
    1. Mobilize combined kangaroo and platypus special forces, bringing in cute koala bears from the eucalyptus groves and dingo operatives just to round out the troops.


Here's a better way to do "tab stops" or an outline.

I. My Outline of How to Take Over the World
  A. America
    1. Increase uncertainty and paranoia
      a. encourage speculation about UFOs, black helicopters, and UN plans to invade the US
      b. enlist Art Bell as my evangelist
  B. Europe
    1. Leverage distaste for Americans
    2. Apply bizarre French awe of Jerry Lewis to my nefarious advantage
  C. Australia
    1. Mobilize combined kangaroo and platypus special forces, bringing in cute koala bears from the eucalyptus groves and dingo operatives just to round out the troops.

Using tables for page-layout can cause a performance hit. You can minimize this by planning ahead, although it will always be slower than not using tables.

The reason is because tables don't really obey the widths you specify -- they're hints. The table needs to know the size of all the contents before it knows what the column widths will be. There are two implications:

  1. The entire text content of the table must be loaded before it knows how to construct it; if you have a 100K HTML document that's all enclosed in a table, you have to wait for all 100K to load before it knows how to display it.
  2. If you have images without specifying he height and width attributes, it has to start loading the images before it knows what the table can look like. It's another good reason to always include height and width attributes.

The way around this is to include the width and height parameters in your image tags. This is a good habit anyway.


Frames are a way to place several HTML documents on the same page.

In order to show several HTML documents on the same page -- side by side, or one on top of another -- by using frames, use the frameset and frame tags. Don't put body tags in your HTML document -- put frameset and frame tags instead, and point to the html documents you want in those frames.

Some HTML purists swear that frames always suck. I disagree. Frames usually suck.

But HTMLementary itself is a convincing argument that frames can be used for Good. Also, a persistent frame that's a navigation bar across the top, bottom, or side of a document can be very effective in easing navigation through a site.

My opinion of frames has evolved over the last several years. Although I used to avoid frames as a general rule, I now use navigation frames quite commonly.

A problem with this approach is that search engines will often find the main page and will not find the framed document that you intended the viewer to see. This implies that the poor schmuck who searched for your document will be stuck in a page with no way to navigate. This single reason is why I shied away from using frames in my serious authoring work for years.

Nowadays when I use frames I include a miniature navigation bar at the bottom of the main content page which includes a link to a parent page that's sure to include the navigation frame.


HTML Tools & Resources

The first priority is getting the syntax correct. I like the HTMLementary tutorial.

Personally, I haven't found a "WYSIWYG" HTML editor I can stand to use. Fundamentally, this doesn't make much sense, as discussed earlier, so I doubt if any HTML editor will ever become as seamless as a page layout program.

My preference is to use an HTML-savvy text editor such as BBEdit with a web browser running. This lets me check my work using an honest editor and an honest browser, rather than a single program that's a half-assed attempt at both

There are newsgroups devoted to HTML. You can glean useful information from comp.infosystems.www.authoring.html, for example. A more laid-back attitude (with less information overall) seems to rule at alt.html.


Practice makes perfect.

When I look at older web pages I've designed, the flaws jump out at me. They're too loud and just plain look bad. The pages I've been designing more recently are much more subdued. I think that helps them look more professional. My style has also been evolving away from the font-like tags more to the document-structure tags.


HTML Zealots

I feel compelled to include an addendum. Friends of mine well into their HTML learning curve have been frustrated and discouraged by people giving them blunt, overwrought, and insensitive criticism.

Zealots are never fun to bump into. Unfortunately, zealots are all too common. The world of HTML design is no exception. HTML purists are adamant about how everyone should write HTML just like they do.

I have a theory for why HTML seems to attract zealots. I think that it's because HTML is simple enough for anyone to wrap their head around. That leads to lots and lots of mediocre HTML authors, and quite a few HTML experts. People who couldn't be, say, a C++ expert can be an HTML expert and simply must make a stink about how everyone else sucks.

So don't be discouraged. Just practice, practice, practice. Don't be afraid to try new techniques, and be introspective about your HTML journey.