Standards in Context
A woman comes home to find her husband beating their kids with a bat. Scared, she runs to the closet, pulls out the handgun that they legally own, and shoots her husband.
A woman comes home to find her husband hasn’t made dinner yet. She goes to the closet, pulls out the handgun they legally own, and shoots him.
Now, we all agree that shooting someone is a bad thing (at least, I hope we do), which is probably why it’s against the law. But is there a jury that would convict the first woman, the one who shot her husband to protect her kids? What about the second wife? In both cases, the man is shot. The difference is context.
Context is such an important concept that I wish it was explicitly taught in school. What’s correct and proper in one context may not be so in another. Yelling “fire” may be appropriate if it was preceded by “ready, aim” but is completely inappropriate when yelled in a crowded movie theater. Context gives everything its meaning, and it still baffles me that web developers don’t quite understand.
What the standardistas (a word first introduced to me today by YUI‘s Matt Sweeney) fail to recognize is that web standards don’t always make sense in every context. I’ve talked before about having some sanity around the use and upholding of standards, and today I’m feeling like waving that flag once again. With context.
When creating a simple, brochureware web site, you rarely need to deviate from web standards and strict implementations because the product is relatively simple; the context indicates that adhering to standards is the best possible solution. If you’re building a next-generation Web 2.0 application that’s really pressing the limits of what a browser can do, you may find web standards to be too restrictive. In that context, following the rules ends up creating additional (unnecessary) work and delivering a sub-par user experience. In that case, I don’t see that there’s even a debate. If getting your application to work (and make money for your company) means bending some rules or breaking others, then I’m all for it.
I view web development not as a science with hard and fast rules, but as an art. As web developers, we’re provided with a canvas upon which to paint our picture and a number of tools to accomplish this task. If tables make your picture complete, go ahead and use them; if custom attributes are the solution, insert away. Just always consider the context in which you’re working before you either accept or reject a proposed solution.
Since I view web development as an art, I don’t see any solution is flat-out “wrong.” In all cases, there are solutions that are optimal and those that are sub-optimal. Choosing the optimal solution sometimes means going against strict standards, and I think that’s okay. Note that it’s not a “bad” solution, it’s not insulting anyone and no evil will befall you for using it; the most optimal solution in this context just happens to not follow the letter of the law. And guess what? The Web will survive.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
2 Comments
You’re right, context is important.
I think there are tiers. When I’m presented with an engineering challenge, I have, generally, a three-part decision tree that I use to help me choose an approach.
I first look to the standards bodies. What does the W3C recommend I do? If that works, great.
If not, the second place I look is at common browser implementations. I’d prefer things were completely codified by the W3C, but when they are not I yield to the most common real-world browser-supported approach. If that works, great.
If not, the third option is to do what I have to do to build a great and efficient user experience.
That said, I think being conservative is wise. I want to use that third catch-all bucket ("do what I need to do") as a last resort only. The reason is that I don’t want to get left out in the cold. Things change fast, and for my project to be as successful next year as I want it to be this year — to be technically sounds across time — its wise to work with (or at least *towards*) standards whenever possbile.
Standards are insurance, but shouldn’t stop you from skydiving.
Thanks,
Nate
Nate Koechley on July 6th, 2007 at 3:37 pm
Well written. I totally agree to your point, context is important. If you want to build the next big web application with rich user experience, there are at times you would want to deviate from the standards slightly.
Even in case of performance, for example the difference between using pure DOM methods vs slapping in the HTML using innerHTML.
Gopal Venkatesan on July 7th, 2007 at 4:01 am
Comments are automatically closed after 14 days.