About web standards, speed, and time

If your work targets the web then it is almost impossible not to hear something like this:  “Man, the standards are moving so slow!” every now and then. Usually this introductory statement is followed by a second part that you wouldn’t say in front of your mom/dad/children.

Basically, the belief is that if there were enough motivation it would have been a matter of months (maybe weeks if you are the type who sees unicorns without consuming stuff legal in Amsterdam and illegal in the rest of the world). Fewer people choose to question not the motivation/drive of the people involved in the standards but their abilities: “if we only have smarter people there”.

If you believe that these are the two main reasons that prevent standards from moving faster than let me tell you that YOU ARE WRONG!

Let me give you an example that illustrates the fact that things cannot be speed up by getting the smartest people around and proper motivation. Let’s start with motivation. What better motivation can a human have then fighting for his own survival? And what about having the smartest guys for the job actually on your team? Basically something even better than an “A” team?

Such a thing actually happened in the 20th century. I am talking about the Manhattan Project (this project created the first nuclear bombs). Despite having the best scientists of the time (and arguably one of the all time best), people like Albert Einstein, Enrico Fermi, J. Robert Oppenheimer, and despite having the best motivation (develop the atomic bomb before the enemy or else the war could have been lost) they needed about seven years to complete the task while spending the equivalent of $25.8 billion and employing more than 130,000 people.

The sad truth is that complicated things take time. And the web browsers and the standards have long passed the point of becoming something that can be called uncomplicated.

In the past two years I have been fortunate to work close with a team at Adobe that is involved in  writing CSS proposals and implementing those proposals in WebKit. I’ve seen ideas moving from inception to hacks/prototypes, and finally to proposals. You know things like CSS Regions, CSS Exclusions, or CSS Custom Filters. And I’ve seen how things that seem to be simple in isolation become complex when considering the whole. Basically, if you add something new to CSS you have to make sure that it will play nicely with the rest of the CSS features.

Another thing you have to take into consideration is to make sure you have throroughly thought though the security implications of a new feature. The Custom Filter spec was on hold at some point this year because there was a possibility (although only theoretical) that a pixel shader could be used to find what links where visited.

For browsers vendors a security issue is also something that can crash the browser. A poor implementation of a complex thing does crash the browser. No one wants this to happen at least not to his browser :D

If it sounds like there is nothing you can do to speed up this process then keep reading for some ideas :). I think that the people who use these standards in their daily jobs web developers and web designers can actually help. And from my point of view these are things you can do:

  1. Make sure you follow the new standards that make sense to you (help your projects/clients). In the unicorn’s country you’d follow all the standards. In the real world this is not going to work thus focus on what you’ve decided that it is important to you.
  2. Create examples that use these standards and make sure you share them (blog posts, conferences, etc). This is hugely important as it helps to validate a proposal. If more people find that spec useful and capable of solving problems then there is a greater chance that that spec is spot on.
  3. Make sure you are vocal about your support for your favorite new specs. One good example of being vocal is Mr. Stephen Hay aka Captain Flexbox. Let the people who are working on the proposal know what you’ve built and ask people involved in the standards what they think about these specs. These days if you go to a web conference at least here in Europe you could easily bump into people from W3C, Chrome, Mozilla, Opera, RIM, Nokia and so forth.

Of course I may be completely wrong here. And maybe these are not the reasons for why it   takes time to get new standards supported in browsers. If you have a different opinion I’d love to hear it.

PS. Although I work for Adobe, this post represents my personal opinion and not my employer’s.

Leave a Reply