soledad penadés

Some years ago, a guy which wanted to communicate with his scientific colleagues decided to create a mark-up language called HTML, with additional stuff, which proved to be quite useful later on, such as the HTTP protocol. Surprisingly for them, these tools came to be very popular, even if (or because) they were quite loosely defined and far away from strict.

Since there was no authority for ruling what should or shouldn't be allowed in it, big companies somehow began to add new features to the language, because they wanted their own products (browsers!) to do funkier stuff than their competitors' products. So if one added BLINK, the other one added MARQUEE, the other one added FONT and so on.

Meanwhile, or maybe at the same time, an abstract entity called W3C was created. Or maybe it existed before! Anyway, although they attributed themselves the maximum authority over all-things-WWW, they were mostly ignored by both software vendors and HTML publishers. Publishers kept doing their loose stuff (if it works why should I change my way of doing things?) and vendors kept developing browsers which tried to fix publishers errors so that pages could be rendered even if they deserved to win one of those WTF!? prizes.

Some time after, people got concerned about the situation. Somebody thought Hey, all of this was meant for communicating but we are actually making it harder to communicate! We need to be serious about this!. And they decided to push for Standards to be used.

"Standards" is quite an abstract term as well, but has proven to be very productive and led to lots of literature, conferences and even job titles. All of a sudden and along with the blogosphere explosion, masses of bloggers began to discuss about Standards, the need for using them and the best techniques for each use. Actually, there was just a handful of people leading the masses, which diligently contributed to rolling the standards snow ball by copying and pasting and trackbacking and pinging to the leaders' blogs, so that they could label themselves with a "I'm a standards developer" in their sidebars, along with a long list of links in the blogroll (including at least one link to A List Apart) and a couple of 88x31px icons proudly proclaiming they passed a syntax validation test.

Parallel to all of this were the normal people which saw themselves in a transition phase where developing desktop applications was a no-no and the general trend was to have a web client interface plus a web server. Some of them just sticked to whatever they found handy, like using tables for laying things out in their application. Some others tried to make sense of all those things which they read in the forums and blogs in the outside world, but it was all too late. It had gone crazy!

When W3C saw their little children going with big bad boys they decided to prepare a long list of directives, working drafts and normatives which they should follow if they wanted to be good and be amongst the golden top of good formats, but they kept being loose and indeterministic, making it harder for developers (instead of easing the process of creating good mark up). More literature about standards was generated, this time resurging in differently flavoured waves: now worried about usability, now accessibility, then XHTML, then XML, then XSLT, then something else. Everything was OK as long as you were worried about standards.

And concerned about standards people, seeing the slow reaction ability of W3C decided to create their own groups, like WHATWG and WHATEVERELSE (joking). Vendors sometimes belonged to both (W3C and independent groups), making the whole thing even more complicated because... who are you going to listen to?

Developers tended to position themselves in two groups: A) the ones trying to make sense about standards. Spending too much time trying to make sense of technical documents which were too many years in "draft" status, while vendors had implemented them however they felt was more convenient, years ago. B) the ones which completely ignored everything, to the horror of group A

Group A believed group B weren't professionals and Group B believed group A spent too much time fixing the errors of others and fussing about abstractions instead of focusing on getting the job done.

And both were right.

If you want to have a developer title, stop creating abominations. Producing invalid code which renders badly in serious browsers is like being a C++ developer and producing code which leaks memory like crazy and then asking the operating system to clean up after your horrible code. You should be kicked out of the profession!

But on the other hand, being a developer doesn't mean one needs to devote all of the precious [free] time to learn about browser render errors, hacks, different box model theories, and so on and on. Being a developer means one wants to develop, not fix what is inherently wrongly designed (unless one gets to work in one of those projects, that is). Developers are here for the business.

What are you here for?