An Easy Way to Find the Validator
If you don't already have it bookmarked, the shortest URL to remember for the W3C validator page is simply to go to the W3C site itself and then hit the link for the actual validator page in the left-hand navbar. I do this very often myself when not working on a system with a bookmark to the validator, mainly because it's easier to type -- only six characters:
w3.org.
After the W3C site loads, just look in the left navbar, which is alphabetical, for a link reading "HTML Validator."
The
W3C site is one you might eventually want to get to know if you keep working with Web standards and other Web-related stuff, as they're the organization that pulls together the interested parties to develop the standards (officially known as 'Recommendations') that the Web runs on. Unless you're fairly technically-oriented, though, their site's a bit easy to get lost in, and lots of what's there isn't too easy to grasp right off the bat. Their validator, however, is one of the best I've found online.
Direct URL for the Markup Validator http://validator.w3.org/ Technical Stuff
Sooner or later in this tutorial, I'm going to refer to your HTML page as a 'document.' Don't get upset by that, though, as they basically mean the same thing.
DTDs and DOCTYPEs and Encodings, Oh My!
Before running a new HTML document (page) through the validator for the first time, there's a couple of things you'll want to check for and possibly add so the validator will work right.
1. The DOCTYPE
First is something called the DOCTYPE, which is an instruction to the validator (and also to your browser, when it's displaying a page) telling it what set of rules to follow while it reads and checks your document.
The DOCTYPE has to be at the very top of the HTML code with no spaces in front of it. Not too hard, eh?
The DOCTYPE points to something called a DTD, which is the set of rules (syntax and grammar) for your document. And every DOCTYPE points to, or specifies, one and only one matching DTD. If you've done a bit of computer programming, then you might roughly compare the DOCTYPE to an include statement, and the DTD to the document actually containing the extra code.
The technical or hard part of using DOCTYPEs and DTDs has more to do with choosing the right ones to use and knowing their effects. However, that goes way beyond the scope of this tutorial, and if you're just starting out, I'll strongly recommend picking the 4.01 Transitional DTD to start with. It's not too old, and is pretty forgiving of mistakes and transgressions. Here's the DOCTYPE to use for it:
Code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Got <frameset>?
If you know about frames, then a 'frameset' document, because of its different markup structure, requires a different DOCTYPE:
Code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
If you don't know what framesets are, you can easily tell which type of document you have by doing a quick search for a
<frameset> tag.
2. A Character Encoding Declaration
The other thing you need to include is something to tell the validator what
character encoding you're using. All you need to do is put this Meta element somewhere inside the HEAD element of your HTML.
Code:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
'iso-8859-1,' BTW, is probably the most common encoding in use, but as with the DTD, there are many others available.
Someone Else's DOCTYPE or Encoding Declaration?
For the sake of simplicity, if you're using a document with other and different DOCTYPEs and encoding declarations already in place, or if you aren't sure what you're doing, or if you're new to markup validation, then I strongly advise using a simpler, 'dummy' document to get yourself started and familiar with the process. The 'dummy' document doesn't really have to have any content in it, and in fact, you can use the template skeleton below:
A Skeletal View of Your Markup at this Point
So now, a skeletal view of your document would look like this:
Code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Your Title</title>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
</head>
<body>
<p>... Your HTML content here ...</p>
</body>
</html> You can see something very similar, labeled 'Template,' at the bottom of this
DTD Reference Page, only that template uses a different DTD, a different character encoding, and an extra XML declaration at the very top.
Geeks in Your Code?!
Also, don't be afraid to leave the DOCTYPE and Meta tag for encoding inside the finished pages you put up on your site. They're actually supposed to be in there, even though many designers either don't know or follow the standards that closely.
Submitting Your Code
This is the easy part.
There're two ways to submit your code to the validator. If your page is already online (up and accessible on a Web server), just type the address URL into the validator page's top text field, which is labeled
Address:, and then hit the form button labeled
Validate URI....
Two things to note about this. One, you DO need to include the
'http://' part (the protocol, for you geeks). Otherwise, the validator whines:
Quote:
|
Sorry, this type of URI scheme (undefined) is not supported by this service. Please check that you entered the URI correctly.
|
Other thing is
not to worry about what URI means -- for most purposes, it's the same as a URL.
If your page is still on your local computer, use the text field marked
Local File:, or hit the
Browse button just to the right of it. Once the URL's in the box, click the button
Validate File. Dealing with Mistakes, Part I
When your page validates correctly, with no errors, you'll see a page that says:
This Page Is Valid HTML 4.01 Transitional! in big black letters near the top. If there were mistakes, then it'll probably read
This page is not Valid HTML 4.01 Transitional!, with a numbered list of error messages below that. And if you were validating an online file, there will usually be a button marked
Revalidate. Remember, that the
Revalidate button is your friend, so once you've fixed some of the mistakes in your code, you can simply click Revalidate instead of going back to the validator's submission (entry) page, retyping the URL, and clicking on the Validate button all over again.
Dealing with Mistakes, Part II, or
Iteration... Iteration... Iteration...
If you're any kind of code jockey, that is, if you do much coding in a real programming language, such as PHP, Java, or JavaScript, as opposed to just HTML markup, then you're probably going to already know this part. It's the cycle where you code to fix things, run them through the compiler, figure out what's actually causing the error messages you get. Then recode, and continue the cycle until either the compiler stops whining about your crazy mistakes, or you have to take a break ...
In this case, instead of a compiler, the machine chewing through your code is just a validator. That's actually good news, though, as moderately-sized web pages will often run quicker than a programming compiler will chew through medium-sized code source files. What's really good though, is that the error messages will have links to actual lines in your source listing which, if things aren't too messy, will contain the actual code error(s) needing fixing.
A typical error message:
Code:
1. Line 7, column 5: document type does not allow element "body" here (explain...).
<body>test
In the error message above, you could click on the underlined link for the line number, '7,' to jump down to that line in a source listing of your code near the bottom of the page.
Although the short descriptions for the errors, like the one above, "document type does not allow element "body" here," may not always mean much to you, there's usually a link included right after the description, like the one above marked "explain...," that can take you to a more detailed description somewhere in the documentation.
One Last Link: the DTD Reference Page Again!
Once you're good at validating the older levels of HTML, you may get motivated to step up to XHTML, which requires one of several different DOCTYPE/DTDs. Here's a reference page with a complete listing of DTDs:
DTD Reference Good Luck Validating!
That's the basics of markup validation with the W3C's markup validator. Hope that get's you up and running. Happy validating.

:rock: