Validation | June 28, 2004
Recently there has been quite a bit of discussion about validation. Some people feel that validation is extremely important, and that all sites should validate without exception. Others feel that validation is just another tool in a developers armoury, to be used if and when they please. My take on validation lays somewhere between these two extremes.
When I build a site, I start by building a number of generic templates. I first mark the content up and then slowly add layers of style. When I’ve finished a template I’ll run it through the validator as a final check to make sure everything is OK. I’ve been coding standards complaint HTML for a while now, so have a pretty good idea what is and what isn’t valid. Most of the time my templates are fine. If they don’t validate it’s usually because of some minor grammatical error that’s easily fixed.
Occasionally bugs do crop up. If it’s a particularly strange bug I’ll run the template through the validator just as a sanity check. It’s always good to tick off obvious problems before starting more in-depth bug busting. For less seasoned developers however, the validator really should be your first port of call. I’m amazed by the number of people who post “browser problems” to mailing lists when in fact the problem is down to invalid code.
Once the templates have been accepted and signed off by the client, it’s time to start building the site proper. This is the time when small validation errors are most likely to creep in. One area that errors occur is in dealing with copy. Clients will supply you with the site content, often in word format, and you’ll simply copy and paste this content into the page/database. However when you do this you can end up entering incorrectly encoded characters like a ” instead of a &rdqou;.
On most jobs you’ll have more than one developer working on the site and not everybody will be as up to speed with web standards as you. Because the templates are already done, it’s usually only minor errors that creep in at this point. Things like image tags or breaks not being closed properly. Authoring tools can also be a source of validation errors, although they are getting more standards friendly with each new release.
Once a site is built I usually give it a quick once over with the validator. On small sites I tend to validate every page, however on large sites this isn’t always practical. It would be handy if the W3C validator had a “batch option”, however until that happens the WDG HTML Validator” is quite useful. Some authoring tools have validators built in but in my experience they tend not to be very accurate.
When the site launches, It’s quite easy for validation errors to creep back in. A very common error being unencoded ampersands in links to external sites. If you’ve built a custom CMS, you could check and correct the errors on input (If you use MT, there are plug-ins that will do this). However this will add to the cost of the build and to be honest, most clients don’t care about validation. They are much more interested in the business objectives of the site and their ROI. The closest I’ve ever come to clients caring about validation is clients who want their site to adhere to priority 2 accessibility checkpoints, and this in it’s self is fairly rare.
The reason I validate sites is mostly out of professional pride. It’s nice to know that you’ve done a good job and created a valid site. However until people start serving up web pages as xhtml instead of text/html there really isn’t the need to encode every ampersand and close every break. I’m not saying that you shouldn’t strive for validation as it really is best practice. Just that sites are living, breathing things that are there to be used, and it’s not always possible to catch every last validation error.
Posted at June 28, 2004 9:41 PM