You may think HTML, like French or Farsi, is an established languageand for the most part, it is, but just like any language, HTML isn't set in stone. Here's a simple example of what can happenand why subtle changes can lead to problems. Suppose a company making browsers wants to introduce a new feature that lets text scroll across the screen. The company's developers tweak their browser to recognize a new HTML tag they created called <marquee> that generates this effect. Millions of Web page designers, grateful for the chance to scroll text across their pages, include the <marquee> tag on the pages they create. Super!
Or maybe not. The problem is, if none of the other browser-making companies know about ormore to the pointsupport the <marquee> tag, then anyone using one of these nonmarquee-supporting browsers won't see the scrolling text.
What's needed is a higher authority to say either: "Yes. Everyone wants scrolling text! All browsers should recognize the <marquee> tag." or "No. That tag clutters up HTML unnecessarily. Use JavaScript instead."
Enter the World Wide Web Consortium (W3C). As the Internet has grown, the W3C has set standards for HTML syntax and best practices. (See www.w3c.org for lots of information about their mission and about Web design in general.) The W3C sets these standards to ensure that browsers and Web pages can interact. The W3C not only determines what constitutes proper HTML, but also what other standards, like CSS or scripting languages, will be encouraged to flourish. Through agreed upon standards, developers create browsers that can read all the approved tags and scripts, and you can be assured that any browser can handle your Web pages.
Still, not everyone agrees on every issue. Remember the <marquee> tag story? Well, it's a true story of one initiative that Microsoft took with Internet Explorer. It was never approved by the W3C. As a result, <marquee> works only in Microsoft's Web programs: Internet Explorer and FrontPage. Netscape has also created tags that were never approved and work only with their browser. These kinds of dialect skirmishes happen all the time, for reasons ranging from innovative developers to monopolistic urges, but the good news is that most major browser developers recognize the need for agreed upon standards and generally defer to the W3C.
Validating Pages
To help folks meet the standards they set, the good people at the W3C provide a way for you to check the quality of your HTML code. Making sure that code meets the standard is called validation.
It's easy to validate a page. Just hop online and visit http://validator.w3c.org/. You can enter a URL or upload a page for validation. The W3C site then spits a report back at you telling you whether or not your code is "well-formed." If the validator finds errors, the report lists every instance, so you can make corrections.
Should You Validate?
The world won't fall apart if you don't validate your pages. As long as you test your pages in a variety of browsers, you can be sure they're working correctly. Also, if you've used FrontPage-specific Web features (like themes, shared borders, link bars, and so on), your page won't validate, so don't bother. (However, you can ignore those errors and use the validator to check the rest of your page.) The only FrontPage authors who sometimes truly need to validate their Web pages are those trying to meet accessibility guidelines (see "Accessibility" below). If this is you, your boss might tell you that you're required by law to validate all your pages, to ensure accessibility.