Over the last few months, I've lost track of how many articles I've seen on the web where people talk about designing a website, only to find out that something wouldn't validate. To compensate, many of these people leave the invalid XHTML or CSS out of the document, and add it in later with javascript since the validator doesn't catch the added content. This relates to the comment I made on the recent "Browser Specific CSS" thread.

As far as I'm concerned, this is worse that having a document that doesn't validate. Being able to put a "Valid XHTML" or "Valid CSS" badge at the bottom of your website is nice, but only if the rendered source of the page is valid. When you add invalid markup with javascript, the rendered source is no longer valid, and the "valid" badge is incorrect. In this scenario, not only is your page invalid, but you made your users download extra javascript and wasted CPU cycles on their machine to insert invalid markup. You're sacrificing load times and bandwidth in order to have a stupid badge at the bottom of the page.

Here's what I've noticed when talking to non-web designers: nobody gives a crap about those badges, and nobody really knows what they mean. On web design or web development sites, maybe the badges mean something. On sites that have nothing to do with these, it's OK to include a mention of standards-based development in the accessibility statement, but badges are just stupid. I think the web standards "movement" is revolutionizing the web, and it's definitely the correct paradigm for web development. However, I view web standards like I view database normalization. Database designers have a mantra: normalize until it hurts, and then de-normalize until it works. That is, develop the absolute best theoretical solution, and then put it into practice using the methods that work best for the available technology. It works with web standards, too: develop the absolute best standards-based solution you can, but then if you need to do something that won't validate, don't freak out about it, because web browsers aren't good enough to allow full standards-based development.

Am I completely off base here? I've been meaning to expand this into a full essay, but have never quite gotten around to it. I'd love to know what more people think.

I would agree with PettyRider. The most important thing is to make sure the underlying (X)HTML is valid. Then, try as hard as possible to make the CSS valid. If you have to use a CSS hack or a browser-specific CSS property that doesn't validate, though, it's not the end of the world. The hack or invalidity shouldn't be hidden with javascript so that you can still claim your word is valid CSS, because it's not valid anymore.