Web developers are standards acrobats

by Sander Marechal

Sometimes people ask me "What is the most important thing in web development?" I used to reply along the mantra of standards based design, using CSS to separate design from content, but I don't think it's the most important skill anymore. Not that standards are a bad thing, it's just that there are so many of them.

Web development, and to a lesser extent also web design, lies on a convergence point of many different technologies. Increasingly these technologies go through some sort of formal standardization so they can "just work" with other technologies. Standards ride the back of the hype that's supposed to be Web 2.0 (the increasing push in standardization probably being the only good thing to come out of the 2.0 hype). As a result, web developers get bombarded left-and-right with all sorts of standards touching on pretty much anything you would want to do on the web.

A quick grab in the bag of TLA's that I used to create this website: XML, XHTML, CSS2, HTTP (these are the obvious one's), RFC 2822 2045 2046 2047 2048 2049 (MIME) and SMTP for e-mail, RSS, Atom and SQL. These are just some of the basic building blocks of a modern website. Beyond this are the more domain specific standards such as XSLT, TrackBack's, SOAP and what-not. Thousands upon thousands of pages of standards, specifications, RFC's and whitepapers. And if that's not enough then there and many more non-standardized technologies you should probably know about. Who said that web development was easy?

You don't need to know all of it, but you do need to know something about all of them. Enough so you can understand what applies where and how to what you want to do. Learning how to handle this overload of information is a vital skill that any web developer should have. Learning how to read standards, not always written in simple language, is too. To make this easier people have created (you guessed it) yet more standards. If you are going to rummage through specification documentation then you probabely want to read up on BNF, Relax NG and XML Schema which are used frequently in such documents. Also, take note of the wording used in the document. There are big differences between MUST, MAY, SHOULD and CAN for example and they are quite distict (yes, there's a standard for that as well :-)

Maybe more important is to see what doesn't apply to you. When browsing around for RSS and Atom documentation I came across OMPL. I didn't bother with it. Trackbacks and pingbacks looked nice, but I decided against it after reading the specs. It's just too open for abuse. Here I like to make another point: If a standard is available for a feature you want, either implement it using the standard or don't implement it at all. Don't offer the world a half-broken implementation.

If the functionality you need is for internal use only then you're more free to go outside the standards. Apply them where it makes sense and leave them by the wayside if they don't. To give a bad example: I have seen a website where a site converted a simple incoming plaintext message to much more complex XML, only to break down the XML into plaintext again so the next stage of the process could store it in an SQL database. The reason was that “all messages had to be in XML”. Use your common sense instead.

Now excuse me while I go off to see if there's anything interesting in the newly approved OpenDocument standard.

Creative Commons Attribution-ShareAlike

Comments

Nobody has posted any comments yet.

Comments have been retired for this article.