A browser provided with HTML code must choose how it will display the web page. Even at the best of times browsers will tend to display web pages in slightly different ways; provided with broken code, each browser may show completely different results.
The best way to avoid this issue is to feed every browser valid code that follows the W3C specification. Any remaining variations in the way a browser displays your web page should be dealt with as exceptions (for example, feeding IE information wrapped in conditional comments.)
The W3C standardizes the HTML syntax and language. As such, it is the canonical reference for the validity of any web page code. The W3C provides a web-based validation service: my suggestion is to use a tool to gain easy access, such the Web Developer extension for Firefox or Chrome, or DreamWeaver’s Validator.
However it is used, the W3C Validator will provide either a green “good to go” bar, or a red error bar indicating that the page has validation errors, listed further down on the same feedback page. While the W3C’s explanation of the source of these errors can be rather technical, reading through them does provide solutions to web page problems.
Occasionally the W3C validator will be inaccessible due to overload or other technical issues. In those circumstances, both the browser extensions and DreamWeaver’s built-in validation service will fail, since they rely on the W3C validation API. If this ever occurs, there are some alternatives:
Often, it is only the “automatic” validator that is offline; you can usually still use the W3C service by copying and pasting your code into a text box on the site (which the validator refers to as “direct input”) or by pointing the service to a file.
Use one of the alternative web page validators described in the next article.
Some common questions:
- “Should every page on my site validate?”
It’s not an absolute requirement unless you are taking one of my classes, but it is a very good idea. Once you know the rules, creating valid code is very easy, and usually makes for better, lighter, well-constructed pages. (Especially in HTML5, which has far looser standards for what makes valid markup.) There are just two cases in which invalid code should be accepted on a page:
You’re adding accessibility to a page that does not naturally support the standard you are using. Adding ARIA roles to an XHTML page would be a good example. Accessibility trumps validity.
You are correctly using features that have not yet made it into the final spec, and therefore will be reported as errors. Schema.org microdata, as used on this page, is a good example.
- “Does a valid page mean that it is well-made or well-designed?”
No. It’s entirely possible to make a page that is poorly designed and coded that still validates. However, validation is an excellent first step.
Validation is only the first step of a suite of tests that are required for a good web page; we’ll talk about the other evaluations in later articles.