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:

  1. 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.

  2. 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…

  3. 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?

Yes. We discussed earlier how anybody can have a standard. So besides using the W3C as a baseline, whose standards do we follow? The first thing we do is look to the masses. What are the really, smart people doing? What sort of publishing trends are going on right now? Are people using floats or absolute positioning? What browsers are people finally shuttering off into irrelevance? We must look to the masses because it is the masses who we work with and it is the masses who we work to reach. The people linked to in this paragraph are not jedi masters because they validate their code. They are jedi masters because they have thrived within the incredible constraints of the browser world to produce beautiful pieces of code, design, and communication goodness. Todd uses a lot of Flash. Doug’s pages can get heavy. Shaun uses a lot of javascript. Jeffrey sometimes creates and deploys color schemes before they are actually in fashion. Dave gets daring and controversial on redesigns. And Dan has committed the ultimate in validation blasphemy by working with us at ESPN.

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

So we’ve learned our ABC’s and our W3C’s, and we’ve studied The Way of the Master, and now we’re ready to levitate above a peaceful grassy area.

The next and possibly most important standard we follow is our own. Tantek Celik followed his own standard when he brought us the Box Model Hack. Suckerfish created the gold standard for dynamic navigation with their CSS/JS dropdowns. And we at ESPN brought typographically rich scalable headlines to the world using Flash and Javascript. None of these things were being preached by the W3C, nor were they in use on the web up to that point. That makes them our own little standards. Standardlings, if you will… or, “rules we follow which others may eventually follow.”

How a standardling sheds its ling

In order to become a meaningful standard on the web, a method must be judged as a generally positive thing, and then deployed on a widespread basis. A good example of this is how Macromedia used the object and embed tags to display Flash seamlessly within web pages. It didn’t conform to W3C specs, but it worked, and it worked well. The method displayed Flash seamlessly on any browser and failed-over silently when set up correctly with javascript. Additionally, users on PC Internet Explorer were able to download the plug-in virtually transparently. As a result of Macromedia’s smart yet “invalid” implementation, the Flash plug-in now permeates over 85% of the world within 14 months of whenever a new version is released. How happy would you be as a web developer if someone told you that everybody in the world would have a shiny new browser within 14 months? Macromedia created a standard from within, and now everyone is reaping the benefits of it. And we haven’t even touched the subject of Flash itself being a standard. That is an incredible accomplishment as well.

If you still need more evidence that breaking the rules can be okay, take a look at the aforementioned Flash headlines we put to use on ESPN.com in 2001. Our method allowed us to create dynamic, scalable, and anti-aliased headlines using any typeface without adversely affecting any browsers. The code used inline javascript and wasn’t totally ideal from an “under the hood” perspective but we felt the attractiveness and functionality gain was worth the paltry fee.

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. :)

Like this entry? You can follow me on Twitter here, subscribe via email here, or get the RSS feed if that's how you roll.

68 Responses:

  1. Design Notes

    As promised, I want to discuss some aspects of the design and structure here. Below is the list of stuff I made note to tackle in this first release of the site: x new design x MT 3.0 – choice…

  2. Plod says:

    Web Standards是可以这样侃的

      Laydies ‘n gentlemen, the blue corner, Steven Champeon, from, uh, from hesketh.com. And the red corner, Mike Davison, fromespn.com, ready…fight!   哦哦,打什么啊,打这个,好玩吧,Validate vs. NOT Validate on Mike Davision’s …

  3. Musings says:

    X-tirpation

    The X-philes get trimmed down to size.

  4. Musings says:

    Poke a Stick in it

    I thought about posting something about politics. Say, about how Rep. Istook (R, Oklahoma) managed to insert a paragraph into…

  5. subtitles says:

    *gasp* You Can Mute Sound From Flash?!?!? – Proclaiming that You *Hate* Standards

    I’ve just been reading a couple of posts by Virtuelvis. Apparently there’s an app that runs in the background that can make sure you never have to endure the shocking terror that is flash-embedded-music. I honestly tend to jump whenever…

  6. My First Offical Post In Which I Tell You About The New Site

    Well, first off welcome to elliotswan.com. And second off, I encourage you to bookmark this site (or even subscribe to my RSS feed), and keep on comin’ back. There should (hopefully) be lots of good content.
    As my first official post, I’v…

  7. […] 11th, 2007 You know, for some reason this guy makes a whole lot of sense. Mike Davidson – March to Your Own Standard You know all the rules, but only through trial-and-error will you learn all of the many exceptions. […]

  8. […] code to check if there are any errors in it. But even though you validate it, its not always valid. Check this article about making your own […]

  9. […] your web site is broken.” “Meh, read this.” “Um, but your site is broken in stupid, careless and lazy ways. You’re not […]

  10. […] Have you run it through the W3C HTML and CSS Validators? Whether you believe in standards or make a great argument for breaking them, the W3C validators are still a great way to catch minor errors in your code. We designers are […]

  11. […] I don’t care. Officially. I’ve taken precedent (kind of) from Mike Davidson, and am purposefully leaving my site erroneous(in some eyes). Just to let everyone know, I’ll […]

  12. […] Marko Karppinen’s study assumes that validity has anything to do with standards-based design, which it clearly does not. […]

  13. […] More Reading…   […]

  14. […] a discussion on web standards, I cited an article on Mike Davidson’s blog.  Someone disagreeing with the points I raised retorted with: You can’t really refer to […]

  15. […] Secondly, opacity is a CSS 3 property, so your stylesheet will not validate. On a lighter note, I honestly don’t think your stylsheets should necessarily validate. I’d rather my site works like I want it to (across most browsers), than have a nice shiny validation badge. But hey, that’s just me… and others. […]

  16. […] – Is this the blog you were thinking of with the "intentionally invalid" badge"? Mike Davidson – March to Your Own Standard __________________ Jay Thompson Thesis Sites: Phoenix Real Estate Guy Phoenix Real Estate […]

  17. […] to semantically describe content. Once mastered, the web developer is able to make intelligent and conscious decisions on the “right” compromises to be made for a given project. We are constantly working […]

  18. […] (CSS). Ska man dÃ¥ följa dessa rekomendationer eller inte? Efter att ha läst ett inlägg av Mike Davidson pÃ¥ hans blogg ändrade jag min Ã¥sikt. I början var jag mycket noga med att följa de regler som […]

Shared
The Ocean in 185 Lines of Javascript:

Mesmerizing. Try tweaking some of the variables in the “sea” section of the code.

“"Design had been a vertical stripe in the chain of events in a product’s delivery; at Apple, it became a long horizontal stripe, where design is part of every conversation.””
Why I Just Asked My Students To Put Their Laptops Away:

A great essay about how toxic everyday distractions can be.

Humanity's deep future:

A group of researchers at the Future of Humanity Institute talk about where our race may be going and how artificial intelligence could save or kill us all.

Steve Jobs speaks about the future at the International Design Conference in 1983:

31 years later, it’s safe to say this is one of the most prescient speeches about technology ever delivered. Jobs covers wireless networking, tablets, Google StreetView, Siri, and the App Store (among other things) many years before their proliferation. A fantastic listen.

How to travel around the world for a year:

Great advice for when you finally find the time.

LiveSurface:

A fantastic app for prototyping your design work onto real world objects like billboards, book covers, and coffee cups. This seems like just as great of a tool for people learning design as it does for experts.

50 problems in 50 days:

One man’s attempt to solve 50 problems in 50 days using only great design. Some good startup ideas in here…

How to Do Philosophy:

If you’ve ever suspected that most classical philosophy is a colossal waste of time, Paul Graham tells you why you’re probably right.

TIME: Why Medical Bills Are Killing Us:

Stephen Brill follows the money to uncover the pinnacle of corruption that is the U.S. Health Care system. A must-read article if there ever was one.

DIY Dot Org:

A beautifully designed site full of fun and challenging DIY projects. I could spend months on here.

The Steve Jobs Video Archive:

A collection of over 250 Steve Jobs videos in biographical order

Self-portraits from an artist under the influence of 48 different psychoactive drug combos.

Water Wigs are pretty amazing.

David Pogue proposes to his girlfriend by creating a fake movie trailer about them and then getting a theater to play it before a real movie. Beautiful and totally awesome.