Fixing common validation problems

  • Revision slug: Fixing_common_validation_problems
  • Revision title: Fixing common validation problems
  • Revision id: 36814
  • Created:
  • Creator: CitizenK
  • Is current revision? No
  • Comment

Revision Content

Summary: Document validation is the single most important tool an author has available. Validating not only makes sure your documents are well-formed, but makes them more robust and ready for the future. Get the details on common validation errors and how to fix your documents so you can avoid them. Like a nation or a house, a page divided against itself cannot stand-- not in standards-compliant browsers, anyway. Every page has a structure, and it turns out that if you aren't careful with your construction methods, the structure will be weakened, flawed, and potentially dangerous. If you've ever loaded up a page in Opera or Netscape 6 or Internet Explorer and had it look totally mangled, odds are that you've inadvertently built a shaky structure.

Imagine building a house on a foundation of sand, or with rubber support beams. Most people wouldn't even bother, and anyone who did shouldn't be surprised by huge cracks in the walls, wildly uneven flooring, or even total collapse of the structure. Yet many authors are shocked to discover that their pages fall apart in recent browsers. The usual reaction is that "the page was fine before!" which is exactly like saying "my rubber-column house didn't collapse on the same day it was built!" Perhaps not, but it was always in danger of falling over.

So how does one ensure a good, solid Web house? Well-structured markup. A clean document structure is absolutely essential to ensuring that your pages will behave in browsers both present and future. Fortunately, fixing up a page's structure after it's been built is a lot easier and less expensive than trying to correct structural flaws in a house! In fact, there are HTML validators out there that can help you identify the problems and quickly correct them. We highly recommend the World Wide Web Consortium's HTML Validator-- not only because it's provided by the same people who are responsible for the HTML and XHTML specifications, but also because most of its error messages provide a link to an explanation of what the error means. Eventually, of course, you'll recognize what each error message means without having to look up the explanation, but when you're starting out these help files are invaluable.

Your goal is simple: to bring your page to a state where it doesn't generate any errors at all. For bonus points, you could try to eliminate any warnings as well, but the important thing is to avoid having errors. There are, practically speaking, two general kinds of errors:

  • Warnings about elements, which are the most serious and can really mangle a page if left uncorrected. For example, an error like "element 'TD' not allowed here", which implies that you either have a TD outside of a table element, or else the validator thinks you do. Either way it's a major problem, and finding out why should be a top priority. An element error is equivalent to a contractor telling you that he left some critical support beams out of your house.
  • Warnings about attributes, which are less serious since most browsers will ignore any attribute they don't understand. This is not to say that attribute errors can be ignored, but they are generally less of a concern than element errors.

As you fix your markup to remove one error, you may find that you generate more-- or that suddenly several other errors go away. For example, if you add a missing end-table tag (</table>) to a document, you might fix every "element not allowed here" error that followed. In any case, the goal of every author should be to have no errors at all of either kind.

Original Document Information

  • Author(s): Eric A. Meyer, Netscape Communications
  • Last Updated Date: Published 05 Mar 2001
  • Copyright Information: Copyright © 2001-2003 Netscape. All rights reserved.
  • Note: This reprinted article was originally part of the DevEdge site.

Revision Source

<p><span class="comment">Summary: Document validation is the single most important tool an author has available.  Validating not only makes sure your documents are well-formed, but makes them more robust and ready for the future.  Get the details on common validation errors and how to fix your documents so you can avoid them.</span>
Like a nation or a house, a page divided against itself cannot stand-- not in standards-compliant browsers, anyway. Every page has a structure, and it turns out that if you aren't careful with your construction methods, the structure will be weakened, flawed, and potentially dangerous. If you've ever loaded up a page in Opera or Netscape 6 or Internet Explorer and had it look totally mangled, odds are that you've inadvertently built a shaky structure.
</p><p>Imagine building a house on a foundation of sand, or with rubber support beams. Most people wouldn't even bother, and anyone who did shouldn't be surprised by huge cracks in the walls, wildly uneven flooring, or even total collapse of the structure. Yet many authors are shocked to discover that their pages fall apart in recent browsers. The usual reaction is that "the page was fine before!" which is exactly like saying "my rubber-column house didn't collapse on the same day it was built!" Perhaps not, but it was always in danger of falling over.
</p><p>So how does one ensure a good, solid Web house? Well-structured markup. A clean document structure is absolutely essential to ensuring that your pages will behave in browsers both present and future. Fortunately, fixing up a page's structure after it's been built is a lot easier and less expensive than trying to correct structural flaws in a house! In fact, there are HTML validators out there that can help you identify the problems and quickly correct them. We highly recommend the <a class="external" href="http://validator.w3.org/">World Wide Web Consortium's HTML Validator</a>-- not only because it's provided by the same people who are responsible for the HTML and XHTML specifications, but also because most of its error messages provide a link to an explanation of what the error means. Eventually, of course, you'll recognize what each error message means without having to look up the explanation, but when you're starting out these help files are invaluable.
</p><p>Your goal is simple: to bring your page to a state where it doesn't generate any errors at all. For bonus points, you could try to eliminate any warnings as well, but the important thing is to avoid having errors. There are, practically speaking, two general kinds of errors:
</p>
<ul><li> <b>Warnings about elements</b>, which are the most serious and can really mangle a page if left uncorrected. For example, an error like "element '<code>TD</code>' not allowed here", which implies that you either have a <code>TD</code> outside of a table element, or else the validator thinks you do. Either way it's a major problem, and finding out why should be a top priority. An element error is equivalent to a contractor telling you that he left some critical support beams out of your house.
</li></ul>
<ul><li> <b>Warnings about attributes</b>, which are less serious since most browsers will ignore any attribute they don't understand. This is not to say that attribute errors can be ignored, but they are generally less of a concern than element errors.
</li></ul>
<p>As you fix your markup to remove one error, you may find that you generate more-- or that suddenly several other errors go away. For example, if you add a missing end-table tag (<span class="plain">&lt;/table&gt;</span>) to a document, you might fix every "element not allowed here" error that followed. In any case, the goal of every author should be to have no errors at all of either kind. 
</p>
<div class="originaldocinfo">
<h3 name="Original_Document_Information"> Original Document Information </h3>
<ul><li> Author(s): Eric A. Meyer, Netscape Communications
</li><li> Last Updated Date: Published 05 Mar 2001
</li><li> Copyright Information: Copyright © 2001-2003 Netscape. All rights reserved.
</li><li> Note: This reprinted article was originally part of the DevEdge site.
</li></ul>
</div>
Revert to this revision