I'm a computer science senior at a state university in Illinois, and fifteen hours a week I work in the campus web office, where my job is cleaning up departmental pages. Somebody in a department learns a little HTML, builds the department's page, adds to it for three years, and then leaves. The page comes to us. I open it up and find things like a table that never ends, links with no closing tag, and (my record so far) eleven BODY tags on one page, each one pasted in along with somebody's hit counter or guestbook code.

The page almost always looks fine in Internet Explorer. That's the problem.

The plea

HTML has a specification. The current one is HTML 4.0, from the W3C, and it says exactly which tags exist, which ones have to be closed, what can go inside what, and how to write an attribute. Browsers are supposed to follow it. Pages are supposed to follow it too. What actually happens is that browsers try to guess what you meant when your page breaks the rules, and different browsers guess differently.

Internet Explorer is a very forgiving guesser. Netscape Navigator 4 is much less forgiving. Here's the classic, which I see about once a week:

Somebody forgot </table>. IE notices the page has ended, closes the table for you, and draws it. Netscape won't draw a table until it has seen the end of it, and the end never comes, so a Netscape visitor gets nothing at all. Every department whose page I've fixed has had somebody tell me "but it works on my computer," and every time, their computer had IE on it. Fix the one line and both browsers agree:

Tony Perlman's Tables for Layout has a whole page about tables that break, and his number one is exactly this: Netscape shows a blank page because a </table> is missing. He prints his pages out and ticks off the tags with a pencil. I use a validator, but I respect the pencil.

And the next browsers may be stricter still. Netscape is building its next browser out in the open, as the Mozilla project, with a new layout engine that's being written to follow the W3C specifications closely. The W3C itself is working on XHTML, a version of HTML where every tag must be closed and every attribute quoted, no exceptions. If your page only works because today's browser guessed right about what you meant, you're betting that every browser from here on will guess the same way. I wouldn't.

Step one: the DOCTYPE

A valid page starts with a line that says which version of HTML it's written in. It goes on the very first line, above <html>. For most home pages, the one you want is HTML 4.0 Transitional:

(You can break it across two lines like that or keep it on one. The specification also gives a longer version with the address of the DTD on the end; either is fine.) In plain words, it says: this document follows a public standard, published by the W3C, the Document Type Definition (DTD) for HTML 4.0 Transitional, in English.

There are three kinds of HTML 4.0:

• Transitional still allows the older presentation tags and attributes most of us use: FONT, CENTER, BGCOLOR, ALIGN. That's what the "transitional" means: for pages making the move from the old way to style sheets.
• Strict leaves those out. All the looks go in a style sheet. If you're starting fresh and you're good with CSS, go for it.
• Frameset is for the page that holds your frames, if you use them.

The DOCTYPE is how a validator knows which rules to check your page against. Without one, it can't check much of anything.

Step two: check your work

The W3C HTML Validation Service is free, on the W3C's own site. You type in the address of your page, it fetches the page, reads it against the DTD your DOCTYPE names, and lists every error by line number. The first time you run one of your pages through, you will get a list as long as your arm. Don't panic. One missing tag near the top can cause a dozen errors below it, so fix the first few, run it again, and watch the list shrink.

Weblint is a Perl program you can run on your own computer, or on your Unix account if your school gives you one: weblint index.html. It doesn't need a DOCTYPE. It looks for the common mistakes (unclosed tags, missing ALT text, odd numbers of quote marks) and gives you warnings in plainer English than the validator does. It will also scold you for using the word "here" as a link, which is fair.

I use both. Weblint while I work, the validator before anything goes live.

What the messages mean

The validator's messages are written for people who read DTDs for fun. (I do, but I understand that I'm in a minority.) Here are the ones you'll see most, in plain words. The exact wording can vary a little.

"But it looks fine."

I hear this every week, so here's my whole answer:

• It looks fine to you, in your browser. A lot of people are on Netscape 4, and every one of those errors is a chance for their copy of your page to come out wrong.
• A valid page is easier to fix. When something does go wrong, you know it isn't the markup, and you can look for the real problem.
• Browsers are going to change. Valid pages are the ones most likely to survive it.
• If I handed in a program that only compiled on one compiler because the compiler guessed what I meant, I'd get it back with red ink on it. HTML deserves the same respect.

Ready? Here are the ten errors I fix most, each with the broken line and the fixed one.