The Struggle for Validation

Design & Development

Portent Staff Feb 28 2008

 

Earlier this morning, Ian sent me an email saying that the Portent Website code was great. Near perfect, even! But one thing was weighing on his mind. We weren’t passing the W3 Markup Validation. That giant red “THIS SITE ISN’T XHTML TRANSITIONAL!” message was searing into his poor SMX-addled eyeballs and I was the closest thing to Visine he could find. I coded this website myself, so I was set on the task of figuring out what exactly was wrong with the code and how I could fix it. But does validation even matter? The page displays correctly for the end user, right?

Why validation matters

We can’t all be valid. Even some top blogs don’t pass validation, including Boing Boing, Seth Godin’s blog and Engadget. Viewing these sites as they are now, the errors aren’t noticeable. Validation exists purely for code junkies and obsessive compulsive XHTML producers. You know, like me. Validation is all part of the grand unification project of the W3C, standardizing code on the web for maximum accessibility. Standards in code are good. Standards in code preserve the sanity of your coders. Anyone who has tried to update old outdated code on a website will agree; if we all just decided on how we were going to use this powerful stuff we call hypertext markup language to begin with our lives would have been easier. Validation exists to ensure your website is future-proof.


It’s also a fantastic debugging tool. Validation will check for errors in your code. It’s also a horrible debugging tool. One error in your code will throw out tons of other non-related, seemingly nonsensical errors. This is partly what makes bug hunting fun, but I am weird like that.

Validating Portent

I noticed one strange error which I pinpointed to be the issue: it was the Google Analytics code. There’s a short line right before the urchin script that we use which determines whether or not we need to use a secure http prefix. It looks like this:

<script type=”text/javascript”>
var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(“<script src='” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’></script>”));
</script>

We don’t use https for any pages on our site, so I reduced the code to this:

<script src=”http://www.google-analytics.com/ga.js” type=”text/javascript”></script>

Removing the single quotes and all the extraneous script. Rebuild the site and run the validator and would you look at that? It was Google all along! My code was brilliant to begin with! I knew I was awesome but now I have the Internet to give me the validation I so sorely needed. Just to be thorough, we checked the CSS. It was also valid. Hooray!
Does this mean that Google gives you crappy code? Not necessarily. The code probably would have validated if I changed the brackets in the javascript to their ampersand equivalents (&lt; and &gt;), but this solution was a bit more appropriate for our needs.

What this means for you

At Portent we strive for quality. We want to present our clients with our best face. Our website is like the showroom model. If we are creating a website for our clients or even just addressing their various Internet Marketing needs, they know that we are able to provide for them the best quality product possible, down to what’s under the hood.
The rules are there to enforce standards, that’s all. Having an invalid website doesn’t make your website invalid, so to speak. But having a valid website means you are providing the best possible product.
And now we can display these little badges here. Everyone loves badges!

Valid XHTML 1.0 Transitional

Valid CSS!

related articles