HOME  → POSTS  → 2004

Standards, Invalidation, and Missing the Point

Tech Industry631 words3 minutes to read

First, read Darice’s post, then come back and finish this post.

I agree and disagree — both concurrently.

On one hand, I see people going overboard about making sure that absolutely everything is flawless code, or else they freak out. On the other hand, I see people who intentionally invalidate their code to try to make a point. Both groups are wrong.

Standards-compliance is a journey, not necessarily a destination. It’s a matter of doing the best you can with the tools and options before you. Had we (Netscape and Microsoft) done things correctly from the get-go, this wouldn’t even be an issue. All websites would be valid, semantic, XHTML 1.0 Strict web documents fed to browsers as application/xml+xhtml. With the current state of the web, this just isn’t possible. At the same time, this doesn’t excuse us from writing the best quality code we possibly can.

You start with the best code in the best browser, and work your way down. Occassionally, you’ll have a loose ampersand, or a tag that has no purely semantic value. If this were an XML world, those things would be unacceptable. But we’re not living in an XML world — we’re living in a much looser HTML world. Web browsers, as good as they’ve become in recent years, are still far from perfect. IE6 still holds the majority of the market share. This isn’t because it’s a better browser, it’s just human nature to take the path of least resistance. This is the kind of world we’re looking at for the next several years. Granted all of this depends on whether Microsoft fixes IE in time for Longhorn or not, otherwise we all simply have to accept the imperfect world that we live in.

Andy said something last January that really made sense. It shouldn’t be about freaking out over a loose ampersand or feeding your sites in a mimetype that IE doesn’t support. At the same time, I’ve seen standards advocates intentionally invalidate their markup to make a point opposite of the first group.

Keith made another interesting point, that standards shouldn’t be something you think about. Standards should just be your de facto method of designing — that’s it!

So far, I’ve agreed with Darice 100%… except for this part:

“Everyone should use the method that fits their design best. The discussion should not be about what method is best but what different method fits which situation best.”

… to which I agree, except when it comes to tables. There are enough standards-aware browsers, and good XHTML+CSS methods to replace any table-based layout… even the complex ones. It might take a bit more work, but that’s how you produce a quality website. Granted, I’m also talking from the side of the gorge that doesn’t use tables anymore anyways.

For those who are still on the table side of the web design gorge, jumping straight into XHTML+CSS design is a pretty tall order. I worked for 3 months solid on a redesign for my website that debuted back in March 2003, and it still used one table to hold everything together (I didn’t understand the CSS box model yet). If we, as standards-compliant designers, come across people wanting to make the jump, we need to help and encourage them to use better methods.

People have asked me why I’ve helped completely random people to build better and better standards-compliant websites, seemingly with no benefit of my own. The reason is because helping one designer build a better website makes the web, as a whole, a better place for everyone. The more people with valid, usable, accessible websites, the fewer bad websites we all have to deal with.

Anyways, these are my thoughts on the issue. I want to thank Darice for inspiring this.

Ryan Parman

is an engineering manager with over 20 years of experience across software development, site reliability engineering, and security. He is the creator of SimplePie and AWS SDK for PHP, patented multifactor-authentication-as-a-service at WePay, defined much of the CI/CD and SRE disciplines at McGraw-Hill Education, and came up with the idea of “serverless, event-driven, responsive functions in the cloud” while at Amazon Web Services in 2010. Ryan's aptly-named blog, , is where he writes about ideas longer than . Ambivert. Curious. Not a coffee drinker.