In a recent blog post, Jeff Atwood of Coding Horror gives this advice:

1. Validate your HTML. Know what it means to have valid HTML markup. Understand the tooling. More information is always better than less information. Why fly blind?
2. Nobody cares if your HTML is valid. Except you. If you want to. Don't think for a second that producing perfectly valid HTML is more important than running your website, delivering features that delight your users, or getting the job done.

It's something of a geek disease to obsess about valid markup, but what does do you get for the effort that it takes to achieve it?

On my current project, we started with a requirement from the customer that the site should validate as XHTML strict. There was some discussion about how much effort this would take to achieve, but in the end we agreed to begin work on this basis, and to take the various difficulties and issues as they came. At the time of writing, we're just about to go into acceptance testing, and the site still validates completely as 'strict'. What has this meant in practice?

Firstly, there have been compromises. Well actually, one compromise of note: the abandonment of using the target attribute to control the types of window used when following different kinds of links. This means that we've resorted to using javascript to open new windows when necessary, and that the small minority of non-javascript visitors will simply find that their browser navigates to the new link in the same window. (Personally, I don't mind that; it simply means that we're regarding popup windows as part of our progressive enhancement strategy. This is reasonable - the native behaviour of web browsers is that links open in the same window - get over it!) The only other thing I can think of is that we're still not sure what the mime-type of an XHTML page should be.

That's the sum total of the differences it's caused from an external point of view. As Jeff says: Nobody cares.

Internally though, as a development practice, it's been pretty useful. Jeff's reasons are good, but I'd add one specific point. Your CSS relies very heavily on the browser being able to validate the DOM correctly. Building in a practice that the developers doing the HTML templating have to validate their output has had a direct impact on the number of CSS bugs and problems that we've seen. This is particularly true when you have cross-browser issues to deal with. The guys are supposed to test on IE and Firefox, but mostly we work in Firefox, and sometimes IE gets forgotten, which usually ends up ten minutes later with someone noticing that the visual output in IE is broken. Validating the HTML from the Web developer plug-in in Firefox is very easy ("Tools-> Validate Local HTML" works very well, as the site isn't currently visible to the w3c validator)

Whenever any issue comes up that's connected with the visual display or layout of the page, the first thing we do is validate it again. Most of the time, the HTML turns out to be broken, and at that point we turn our attention to fixing it. Previously, we might well have invested unnecessary effort on trying to debug the CSS. So in this sense, validating your HTML is akin to paying attention to your compiler warnings. Disciplined developers who keep their output free of warnings, are immediately alerted to real issues because they aren't swamped in the warnings generated by all those things that weren't important enough to fix.

In the grand scheme of things, standards generally help. Long term, and over time, that is. In the short term, well the history of the web has shown that if you need to get results today, well don't wait for the standards to be widely adopted. The downside is that we have to live in a world of browser incompatibilities and just accept the extra work that this causes. So yes, I want to be standards compliant, but only once the standards support the functionality I want to create. Validation matters, in that it without standards, nothing ever gets better, but it costs us effort that may not give us a personal short-term payback. A classic tragedy of the commons.