HTML, XHTML and CSS All-In-One for Dummies - Andy Harris [20]
Figure 2-4:
I’m checking the oxWheels page to look for any problems.
Figure 2-5: Twelve errors? That can’t be right!
Examining the overview
Before you look at the specific complaints, take a quick look at the Web page the validator sends you. The Web page is chock-full of handy information. The top of the page tells you a lot of useful things:
♦ Result: This is really the important thing. You’ll know the number of errors remaining by looking at this line. Don’t panic, though. The errors in the document are probably fewer than the number you see here.
♦ File: The name of the file you’re working on.
♦ Encoding: The text encoding you’ve set. If you didn’t explicitly set text encoding, you may see a warning here.
♦ Doctype: This is the doctype extracted from your document. It indicates the rules that the validator is using to check your page. This should usually say XHTML 1.0 Strict.
♦ Root Namespace: If you use the template I give you, you always see the same namespace, and you don’t have any surprises.
♦ The dreaded red banner: Experienced Web developers don’t even have to read the results page to know if there is a problem. If everything goes well, there’s a green congratulatory banner. If there are problems, the banner is red. It doesn’t look good, Aesop.
Don’t panic because you have errors. The mistakes often overlap, so one problem in your code often causes more than one error to pop up. Most of the time, you have far fewer errors than the page says, and a lot of the errors are repeated, so after you find the error once, you’ll know how to fix it throughout the page.
Validating the page
The validator doesn’t always tell you everything you need to know, but it does give you some pretty good clues. Page validation is tedious but not as difficult as it might seem at first. Here are some strategies for working through page validation:
♦ Focus only on the first error. Sure, 100 errors might be on the page, but solve them one at a time. The only error that matters is the first one on the list. Don’t worry at all about other errors until you’ve solved the first one.
♦ Note where the first error is. The most helpful information you get is the line and column information about where the validator recognized the error. This isn’t always where the error is, but it does give you some clues.
♦ Look at the error message. It’s usually good for a laugh. The error messages are sometimes helpful and sometimes downright mysterious.
♦ Look at the verbose text. Unlike most programming debuggers, the W3C validator tries to explain what went wrong in something like English. It still doesn’t always make sense, but sometimes the text gives you a hint.
♦ Scan the next couple of errors. Sometimes, one mistake shows up as more than one error. Look over the next couple of errors, as well, to see if they provide any more insight; sometimes, they do.
♦ Revalidate. Check the page again after you save it. If the first error is now at a later line number than the previous one, you’ve succeeded.
♦ Don’t worry if the number of errors goes up. The number of perceived errors will sometimes go up rather than down after you successfully fix a problem. This is okay. Sometimes, fixing one error uncovers errors that were previously hidden. More often, fixing one error clears up many more. Just concentrate on clearing errors from the beginning to the end of the document.
♦ Lather, rinse, and repeat. Look at the new top error and get it straightened out. Keep going until you get the coveted Green Banner of Validation. (If I ever write an XHTML adventure game, the Green Banner of Validation will be one of the most powerful talismans.)
Examining the first error
Look again at the results for the oxWheels1.html page. The first error message looks like Figure 2-6.
Figure 2-6:
It doesn’t like the end of the