..about validating

Does it matter?

A gentleman sent me a one-line solution to the IE5PC box width problem. It's a sharp bit of code and uses an IE expression. He asked if there was any reason we shouldn't use this instead of Tantek Çelik's four-line method. I didn't see why not, but someone else did: because it doesn't validate.

Well, so what? The code isn't really wrong, it's just using a non-standard IE expression to solve an IE glitch. A browser specific solution to a browser specific problem. No other code is harmed and it looks good.

Well... not quite.

My view is validation is very important, and not because I'm a stickler for rules. I actually dislike rules. My hair is long, I question authority, and generally I'm a bureaucrat's bad day. But sometimes when I question authority I find I agree with the answer. It's important to keep your ears open while questioning.

There's a completely practical reason why an invalid fix that looks fine in IE and Opera and Netscape is no good. And it has to do with the nature of our web's code.

I don't think it's widely understood how unique the code is.

This is an attempt to make a code that can go decades and centuries, getting broader in scope without ever shutting out it's early versions. Because that's what we need the code to do: this code is for recording what we think. There are no paper backups of the web. Every day we put more on it that we're not putting in our traditional medias. If we don't use extensible code, then our current history evaporates with the next minor tech change. We've never had this problem before. Before a mark on a page could go centuries; there'd always be daylight to read it by. This is a new problem and it required a new solution.

The code has to expand it's capabilities as we do, yet never in a way that blocks out our earlier documents. Everything we put down now will continue to be readable as long as it was recorded using markup valid in its time. Because at the core the code is the same code.

It's a big concept. This code is a remarkable undertaking. And it needs some rules to work.

We have to validate because that's the only way to know our code won't fail as the syntax develops. We can't be assured that a Microsoft expression won't mess something down the road, because it isn't a form recognized by the code's architects at the W3C. They, and the architects who will replace them, will be extending our code based on what they know is unused syntax: everything that isn't in the current spec. They have no way of knowing all the specialty browser expressions like Microsoft's. They can only work from what is and isn't in the spec.

So you and I need to make sure our code uses only the existing syntax and the existing rules. Not add any invalid markup from an outside source that can run afoul of future syntax and future rules. And the only way to be sure is to run the validator. Fortunately that's real easy. If it's new to you, here is the validator. And to make it even easier, there's these wonderful Gazingus bookmarklets.

... last night I walked past a piece of ten year old tech on the scrap pile. It was worth $135,000 when it was new. That's not going to stop happening. So it's key that we tie our long term aspect, our culture, to things that aren't tied to short term tech. That's what this code is about. That's why we need to validate.

Did you come here from somewhere else? Not sure what is going on? Start at the beginning.