March to Your Own Standard
So what’s up with the little grey button at the bottom of this site? It is my official Invalidation Badge. It’s mere presence on every page of this site renders my entire domain XHTML 1.0 Non-Compliant. Invalid. Erroneous. Whatever you want to call it. Here are the various crimes this one line of code commits:
- An ampersand is not properly encoded
- An alt tag is missing
- An attribute called “myfavoritetag” is made up
- An attribute is missing quotes
- A script tag is missing its type and language attributes
- A non-closing tag is missing its trailing slash
- A tag is upper case… gasp!
By invalidating my entire site with this one line of code, I ensure that I am made aware the instant it matters. The instant this stuff starts to break anything in the real world, I will know. If I only had a few small errors on a few random pages around my site, I could easily miss the day when “the big switchover” happens and wind up with broken pages I don’t know about. And since this code is in the form of a server-side include, I can freely remove it with a few clicks.
It’s kind of like carrying a canary down a mine shaft with you. As long as the canary is alive and chirping, you know you’re okay for air. Actually, I guess it’s not really like that.
You moron, what are you trying to prove?
Nothing to prove really. It’s just a reminder that web standards are about a lot more than validation. Web standards are about all the processes involved in publishing information over IP. If you have a big red button at your company that employees press to make their pages live, that’s a standard. It’s your own strange and puzzling standard, but it’s a standard. If someone is going to work at your company, they need to learn how to push the big red button to publish their pages.
So how do we pick what standards to follow when we’re publishing on the web? If we pick standards that nobody else practices or recognizes, the benefit of the standard is limited to our own little world.
Who can we look to for guidance?
First we look to the W3C. We don’t look to them because they have any authority. We don’t look to them because we have to. We look to them because their very charge is to help us and their existence is for our benefit. They are not owned by Microsoft and they are not paid by the NRA.
W3C specifications are usually (but not always) detailed and well-thought out. They give us sets of tags with which to classify our data. They give us proper syntax with which to use these tags. They give us methods of styling our information with external stylesheets. And finally, they give us the ability to add intelligent behavior to our content using the document object model.
After a several days of studying, some people could get a rough handle on the above methods. After several weeks, the same people could probably claim they have intermediate web skills. And after several months, these individuals might have more web skills than anyone in their neighborhood.
So what have these people learned sitting in the closet with their laptop and their O’Reilly book? How to deal with deadlines and workplace personalities? How to integrate art, editorial, and marketing? What web publishing is all about?
Not at all.
They’ve merely learned the building blocks of deploying 0’s and 1’s on the web. That may sound insignificant, but it’s not. It’s more than 99% of the world knows, and probably a good amount of the entire code-writing profession.
Alright, we’ve got our W3C stripes, now what?
First let’s go over what we shouldn’t do:
Don’t join the validation army
Just because you can validate your code doesn’t mean you are better than anybody else. Heck, it doesn’t even necessarily mean you write better code than anybody else. Someone who can write a banking application entirely in Flash is a better coder than you. Someone who can integrate third-party code into a complicated publishing environment is a better coder than you. Think of validation as using picture perfect grammar; it helps you get your ideas across and is a sign of a good education, but it isn’t nearly as important as the ideas and concepts you think of and subsequently communicate. The most charismatic and possibly smartest person I’ve ever worked for was from the South and used the word “ain’t” quite regularly. It didn’t make him any less smart, and, in fact, it made him more memorable. So all I’m saying is there are plenty of things to judge someone on… validation is one of them, but certainly not the most important.
Don’t move on to other technologies thinking you’ve mastered the web
A true mastery of the web takes years. You know all the rules, but only through trial-and-error will you learn all of the many exceptions. In fact, one could argue that the web has more exceptions than rules when it comes to how things display in browsers. One would probably lose that argument, but nonetheless…
Don’t get all Unabomberlike on us
Running your Olsen Twins Fan Club site out of the broom closet is not going to teach you anything about the collaborative environment of electronic publishing. Spewing validation manifestos on message boards isn’t going to show you how to listen, negotiate, compromise, and execute. You need to get out and work with the designers, writers, and businesspeople who will make your own work much much better.
Can we get back to web standards please?
These people are important because they are uniters. They bring the designer and the coder together. They bring the business team and the production team together. They bring the rules and the exceptions together. It is their ability to mitigate in a world of competing interests which sets them apart. And they are nice guys to boot. We look to people like this to help us learn the best practices the W3C cannot teach us. We learn things like how to best integrate Flash into a publishing environment, how to use multiple stylesheets to change the color of a site every day of the week, and how to replace vomit-inducing browser text with anti-aliased typographical goodness.
Standards exist for the benefit of the web worker almost more so than the end user, and by following the best practices set forth by the best people in our industry, we ensure we are equipping ourselves with a versatile skillset which we can take into any environment. We may never work at a company which requires us to push a big red button to publish our pages, but we almost certainly will work at one which requires some of the methods set forth by these and other pioneers in the web publishing world. If you think standards are all about helping the disabled, you’re wrong. Accessibility is about helping the disabled, and there are both good and bad accessibility standards in use on the web today. Standards, on the other hand, exist so that we can use the minimal amount of labor and energy to create the greatest impact possible.
True enlightenment comes from within
How a standardling sheds its ling
But what happened next is what’s really important. Shaun Inman, an ESPN user and churner of much butter in the web design world, came up with a way to deploy these Flash headlines in a much better way from a coding standpoint. It’s called IFR and If you haven’t seen it yet, check it out. It’s what Shaun uses on his site, it’s what I use on this site, and it’s what we’ll be using on ESPN.com and other Disney properties in the very near future.
So what we have now in IFR is a very promising young standardling which is about to be adopted by a very big company. It’s the result of our original imperfect implementation, followed up by a near-perfect implementation at the hands of the I in IFR. Do I really care how many people adopt it? No. It benefits us and our users and that’s all I care about. If it benefits you and your users, then great, use it too. And don’t forget to shoot a nice thank you note to Shaun. Maybe one day it will be the defacto standard of how to enhance typography on the web.
And now back to that Invalidator Badge thing
So aside from IFR, I am excited about another standardling which makes its way into this world on this very page. I’m officially opening up the Invalidator Badge to the public domain. As Al Gore would say, “It’s Open Source.” Simply copy and paste this code…
… anywhere on your site and let the fun begin. If you’re really good, you can even further invalidate the code in other harmless ways. Remember, this project is what you make it and my code is but a starting point. You’re welcome to use the badge as is and I think I might even publicly shower with compliments the person who is able to put together the most invalid benign code sample in 100 characters or less.
And then maybe after you’re done with that, you can get some real work done. :)