Validation and web standards have been on my mind a lot lately so it’s pretty fitting that Jeff Atwood would write a post titled “HTML Validation: Does It Matter?”. I swear that guy has a wireless link straight to my brain. Fucker…

I couldn’t help feeling that validating as HTML 4.01 strict, at least in our case, was a giant exercise in to-may-to versus to-mah-to, punctuated by aggravating changes that we were forced to make for no practical benefit. (Also, if you have a ton of user-generated content like we do, you can pretty much throw any fantasies of 100% perfect validation right out the window.)

To be clear, I agree 100% with him on this. The act of validating a website’s (X)HTML is just a HUGE freaking waste of time. I’ve gotten a lot of flack for this opinion but it’s mine and I stand by it.

In the world of web development the above statement is heresy but it’s true none the less. The reason it’s true is because NO ONE BUT WEB DEVELOPERS CARES about validation, time is expensive and, in the end, most sites have no control over their content anyway so you’re essentially pissing in the wind even attempting it.

The thing is, I have yet to have my mother ask me why my sites don’t validate. I’ve never had my girlfriend, neighbor, friend, mechanic, doctor, dentist, veterinarian, or, hell, anyone, ask why my site doesn’t validate. All they care is that it works on their computer / browser. That’s all anyone, who matters, cares about; web developers just aren’t a part the “He Who Matters” club.

Like most new web developers I was initially bitten by the validation bug and fought vehemently at the company I worked at to make sure our sites validated. Now, admittedly, this was around 2001 when there were only 2 web browsers to care about, Internet Explorer and Netscape (just barely though), on Windows only of course, so validation wasn’t the chore it is now.

Hell, back then it was perfectly acceptable to just place a note on your site saying that it only worked with a particular browser on a particular platform and no one cared. It was just an awesome cop-out true, but a practical one. Good times…

My attempt failed though because of the amount of work required to validate our code base. Obviously, this is due to poor design of the program architecture and not the act of validation itself, but the example does highlight a significant issue with the idea of validation. The difficulty in implementing validation is a rampant issue throughout most companies and since they can’t quantify the project, and since the experience doesn’t improve, it’s just not practical to the bottom line.

Which is the other issue with validation; there’s just no money in it. It doesn’t matter how many hours you spend or how many lines of HTML you refactor; at the end of the day the end user experience is no better than it was before you started the validation process.

Of course, this is assuming you have a working site to begin with. If you don’t, you’ve got bigger problems 😊

Now, the validation trolls may say money shouldn’t be a part of the argument. That it’s up to the developer to know their skills and raise the level of their markup. That it’s still important to ensure 100% validation. My employers’ clients beg to differ.

Not to be patronizing, but it’s important to recognize this point. Not all of us work in ivory towers built on COBOL and mainframes. In my experience, most us have too many projects going on at the same time with too few resources and too little time. From a business standpoint it makes sense; more projects done by fewer people equals more money.

$money = ($project*$x)/($employees-$y);

For example, on my team, we do everything ourselves; the server hardware, database, scripting (both server and client), CSS and HTML. And it needs to be done yesterday. Out of all of the above the only one, well 2 really, that has zero downside for not following the “rules” is HTML (and to a lesser extent CSS). It’s not a hard choice.

And then there’s the user generated content curse (UGC). As Jeff mentioned, if you let users add their own HTML into your site you’re done. Give up. It’s never going to happen. YOU ARE FUCKED. All it takes is one user to confuse:

with

<br>

to completely destroy your validation plans.

Not that validation, as an idea, is bad though. Having a tool that will parse provided (X)HTML and present a detailed list of possible issues is a really nice debugging tool. I use it a great deal when fixing cross browser compatibility issues.

The thing you have to keep in mind while doing this is to take all output with a grain of salt. Just because there are errors doesn’t mean you have to spend time fixing them; just those errors that fix the issue in question. Stick to using it to find malformed tags and you’re good; attempt to fix issues that don’t improve the experience for the user and you’re just wasting your time and your client/companies money.

Of course, Jeff stole that thought too…

There is some truth to this. Learning the rules of the validator, even if you don’t agree with them, teaches you what the official definition of “valid” is. It grounds your markup in reality. It’s sort of like passing your source code through an ultra-strict lint validation program, or setting your compiler to the strictest possible warning level. Knowing the rules and boundaries helps you define what you’re doing, and gives you legitimate ammunition for agreeing or disagreeing. You can make an informed choice, instead of a random “I just do this and it works” one.

Get out of my head Jeff. Please man….