Fixing common validation problems

If you are not careful, you risk building your web pages on assumptions of browser behavior, that were never intentional, never documented and likely to not hold in the future. These assumptions are called quirks, and should be avoided in your web pages. Quirks may cause web pages to behave differently in different browsers, and even different versions of the same browser.

One way to help you make web pages, that work across multiple browsers is to use an HTML validator, that can help you identify problems and quickly correct them. An often used validator is the World Wide Web Consortium's HTML Validator. It's provided by the same people who are responsible for the HTML specification, and more importantly 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.

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.

DOCTYPE and validation

Validators typically use a DOCTYPE to choose which standard to validate against. In browsers, a DOCTYPE is only used to switch between quirks mode and standards mode. Before you validate your document, it is important to have a correct DOCTYPE for mainly two reasons:

  • If browsers use quirks mode, validating your document will not help you make it behave the same in different browsers. Browsers deliberately act differently in this mode due to backwards compatibility.
  • If you validate your code against a different standard than the one used by browsers, validation will just lead you in the wrong direction.

The DOCTYPE must be placed in the top of your HTML document like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset=UTF-8>
    <title>Hello World!</title>
  </head>
  <body>
  </body>
</html>

This example uses the HTML5 doctype. There are several good reasons to validate against HTML5 rather than the older HTML4 or XHTML standards, even if your HTML document does not use any of the new features introduced in HTML5.

  • HTML5 is the standard modern browsers are trying to implement. Validating against HTML4 may put you in the wrong direction, as it may give you advice that is no longer correct in HTML5 and has never been correct in browser implementations.
  • Validating against XHTML will most likely lead you in the wrong direction, since your document is most likely not interpreted as XHTML.
  • Validation is not the best method to ensure backwards compatibility with older HTML4 browsers, as those browsers are typically less standards compliant.
  • Great care has been taken to make HTML5 backwards compatible with older browser implementations.

Once you've added this element to the top of your document, then you can use the Document Type option "(specified inline)" and the W3C validator will use the DTD you've declared in your document to validate the markup.

Common problems

There are a few errors that authors will likely see many, many times as they validate pages. There are also a few things that a validator might not catch (software is generally as perfect as the humans who write it). Here are a few of the most common errors and pitfalls to avoid.

Forgetting important attributes

If you get an attribute-related error, it's very likely going to tell you that you forgot to include a required attribute. These include:

The alt attribute is important for accessibility reasons, as its inclusion assists users who are using text-only or audio browsers.

Improper nesting of elements

Over the years, authors have developed a number of tricks that get the effects they want with a minimum of typing, and which avoid certain display effects. Unfortunately, some of these are based on wholly invalid markup and will cause a validator to choke. They'll also lead to display and functionality problems in standards mode.

One example is wrapping an inline element like <span> around one or more block-level elements like <div>, which is not allowed. For example the following markup is structurally incorrect:

<span>
  <div>A block level element in an inline element</div>
</span>

On a related note, some authors like to avoid the "white space" that the <form> element introduces inside table cells by doing something like this:

<table>
  <form action="script.cgi" method="get">
    <tr><td>(...form widgets here...)</td></tr>
  </form>
</table>

That will trigger an error because you can't put <form> inside a table but outside a table cell. You could wrap the <form> element around the entire table, or put the form into the table cell and use CSS to set its margins to zero-- but in that case the entire form would have to be placed within that single table cell. If you're using a table to lay out your form, then you need to wrap it around the whole table, or around an entire section of the document if that's feasible.

Improper comments

Although it may seem picky, it is important to be sure that you format your HTML comments correctly. The correct form of an HTML comment is:

<!-- comment -->

That's two dashes at either end, not three as some authors like to include. In general, you should avoid any sequence of dashes within a comment, and stick to the allowed pair of dashes to help mark the beginning and end of the comment. (See HTML 4.01, section 3.2.4 for more information.)

Ampersands

Because the ampersand character (&) is reserved for marking character entities, authors should never use raw ampersands in their HTML source-- and that includes ampersands inside URLs! Thus, any URL that needs an ampersand should be written like this:

http://www.example.com/path/doc.html?var1=val1&amp;var2=val2&amp;var3=val3

Each instance of &amp; will be translated by a Web browser into an ampersand, without triggering validation warnings.

Attribute Value Presence and Quotation

If you're validating against an XHTML DOCTYPE, then all of your attributes must have values, and all of these values must be enclosed in quotation marks. You must also close every element you open, so in those cases where there is no close tag, the end of the element should include a forward-slash. These are requirements of XHTML (and with XML-based languages in general), and so the validator will flag any instance where you do not follow these rules. One example of valid XHTML markup that will differ noticeably from historical HTML:

<input type="checkbox" checked="checked" name="prefSys" value="MacOS" />

Note the addition of a (quoted) value to checked and the slash at the end of the tag. Without these additions, this markup fragment would not be valid XHTML.

Warning: Please make sure that your are actually using XHTML and understand its limits before you validate your document against XHTML.

The font element is deprecated

The purpose of the deprecated font element was to specify typeface, color and size of the enclosed text. This is however much better done with CSS. The quickest way is to directly replace the font element with a span element and add the style as inline CSS color, font-family and font-size:

<p><font color="blue" face="Helvetica">
  A really <font size="+1">big</font> shoe.
</font></p>

... becomes:

<p><span style="color: blue; font-family: Helvetica, sans-serif;">
  A really <span style="font-size: larger;">big</span> shoe.
</span></p>

... or even more concisely:

<p style="color: blue; font-family: Helvetica, sans-serif;">
A really <span style="font-size: larger;">big</span> shoe.</p>

Note that though this is the most direct change you can make to fix the validation errors, you should consider learning how to use CSS properly, instead of adding style information directly to element.

The center element and align attribute are deprecated

The CSS text-align property specifies how text or inline elements (like an image) are aligned within an element.

<p style="text-align: center;"><img src="..." width="..."
height="..." alt="..."></p>
// will center the image inside the <p> element

CSS margin-left: auto; margin-right: auto; properties will center a block-level element within its containing block. Defining margin-left and margin-right is for block-level elements. When both margin-left and margin-right are auto, they are set to equal values, thus centering a block-level element within its parent.

The bgcolor attribute is deprecated

The bgcolor attribute can be replaced with CSS background-color.

If you have

<td bgcolor="green">
... content here ...
</td>

... can replace it with:

<td style="background-color: green;">
... content here ...
</td>

The applet element is deprecated

If your page makes use of the <applet> element to embed a Java plug-in, use the <object> element instead, or replace your use of a plug-in with open web standards like HTML, CSS and JavaScript.

The marquee element is invalid

Marquee can be replaced with content string inside a <div> or <span> rotating over time with JavaScript. It must be said that this sort of effect is discouraged. Studies have shown that constantly moving objects or moving text disturb reading and weakens peripheral vision. If after webpage assessment and consideration, you still want to include a marquee effect in your page, then you can use the following tutorials:

The bgsound element is invalid

Use the <audio> or <object> element instead:

<object data="audiofile.wav" type="audio/wav" ...></object>

Please note that while playing sound automatically in the background may seem cool to you, your visitors often find it extremely annoying. According to the survey page What we really hate on the web, 41.9% of survey respondents will avoid sites that automatically play music; 71.1% strongly dislike sites that automatically play music.

Validating CSS

Free online CSS validation services:

Conclusion

Although it may seem like more work at first, validating your markup now will pay off handsomely in saved time and effort later. Not only will your documents stand a much better chance of being properly displayed in all current and future browsers, but it will be much easier to maintain your documents, or even to convert them from HTML to another markup language such as XML.

Although the ideal goal is to have pages that generate no validation errors and no warnings, your primary concern should be the elimination of actual errors. Once you've cleaned things up so that you no longer get errors, then you can turn to the task of styling the document and feel confident that the page will display in just about any known browser, as well as any decent browser to come.

Also on MDC

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.

Document Tags and Contributors

Tags: 
 Contributors to this page: groovecoder, Sheppy, Dikrib, Nickolay, Leofiore, BenoitL, GT, George3, Mgjbot, Mathieu Deaudelin, NickolayBot, Dria, CitizenK
 Last updated by: groovecoder,