Take Away

Web projects benefit by using correct and standard valid code as much as possible. Running every page through the W3C HTML and CSS validators aids this effort. It also helps to quickly resolve problems. But, it is not necessary that the page pass validation. There are good reasons to use nonstandard code. For example supporting MS IE and at the same time supporting standards compliant browsers. In a team environment, there should be an approval process. Group concensus can establish a list of acceptable exceptions and the technical lead or development team can signs-off on the additional exceptions.

To Validate or Not to Validate?

More importantly, should page validation be required of all members on a development team?

Like religion and politics, this topic isn't brought up in polite company. It can be an quagamire of contention among many Web developers. The reason is the clash between zealous adherence to standards compliance, and pragmatism. The most ubiquitous browser has poor support for W3C standards making it near impossible to create cross platform standards compliant pages that are interesting.

Some Web authors proudly display the W3C's "This page validates" icon, and others deride the display of such icons. Some authors work diligently to make their pages compliant with the W3C standards going so far as to create esoteric hacks to achieve compliance. Others never attempt to create standards compliant work. It seems that the markup for most pages on the Web isn't valid according to W3C. Both sides of question have valid arguments. Although, they often boil down to "It is a waste of time because the proprietary features I need to use won't validate," or "We need to insist on using only standards based code, which will force browser makers to support the standards."

The primary justification for creating pages that pass the W3C's validation is that those pages are interoperable (or, more accurately, using only compliant code will force browser manufactures to create compliant browers). Validated pages are more likely to work on other internet enabled devices like PDA's or Cell Phones. Thus making content accessible to a wide audience. That, after all, is the promise of the internet and the World Wide Web.

Like many aspects of development, the hype is better than the reality. Pages that pass the W3C's validation are not truely interoperable. They work on all browsers that support the W3C standard faithfully and a growing number do, but cross platform development requires more work. It should be noted, however, that a standards compliant page is a good start (and that is the exact point to be made later).

The early days of the Web were chaotic. Netscape, Microsoft, and others competed by adding proprietary features to their browsers forcing developers to choose different strategies. They could to write code for one browser, add a lot of script and hacks to adapt the code for each browser, or skip advanced features and code at the lowest common denominator. The W3C was established to create order out of the chaos. But, they do not have the authority to impose standards and can only make recommendations.

Developers supporting Mozilla, Firefox, Netscape, Safari, and many other newer browsers will find W3C standard compliant markup (and CSS) works well and there is little need to make browser specific adjustments. The Microsoft developers will find that many of the markup features they like are noncompliant. Further more, Microsoft editing tools like Visual Studio in .Net and Front page have default settings that generate noncompliant markup, while take advantage of IE feature implementations.

Many developers believe validation is a waste of their time especially since they know that their pages will not validate. And, they believe the work to get their pages to validate creates more complicate code. Writing cross browser compliant code is a skill that takes practice, and the code does not need to be significantly more complicated. However, it may not seem to be expedient to put the effort out. This is an especially significant point since browsers often do a good job rendering invalid markup.

My experience has been that running pages through the W3C validator is always instructive, catches errors, and helps resolve many problems. Working toward compliant code produces cleaner HTML and CSS. The pages are more maintainable and reliable. They are more likely to work adequately a cross platforms, and with small platform specific adjustments, the will work well a cross platforms.

Yet, the use of noncompliant markup or CSS, which is ignored by compliant browsers, is sometimes the simplest way to achieve interoperability.

A policy of validating every page is justify because of the improvement in code quality. A policy that every page be 100% valid, however, is not justified since noncompliant code is better than confusing hacks based on browser flaws or locking out support of certain browsers. But, the use of noncompliant code must have a good reason. In a team setting, there should be an approval procedure for any invalid code before it is allowed. Either the technical lead signs-off on the exceptions or group concensus establishes the acceptable exceptions and documents them in a style guide. A notation should be made in the code indicating that the code is an approved exception.