the decline of standards

standards huh

A web standard is a trusted, solid, supported and unique solution to a particular problem. When people are talking about "web standards", they mean the collection of all separate standards involving front-end development. This might sound like a somewhat trivial point to make, but there's a good reason to have it out of the way.

The plural of the word "standard" often indicates that there isn't really a true standard to begin with. A standard can only be a true standard if it is unique in its implementation. Multiple standards can exist for fixing a particular problem, though resulting in a weaker and less pure use of the term. The existence of multiple standards is what we've been fighting all these years, trying to approach a "one problem - one solution" situation.

2009 turned out to be a pretty bad year for web standards.

browsers and evolution

In 2009 five big browser vendors ruled the world of web. Internet Explorer, Firefox, Safari, Chrome and Opera are divided among four different families of rendering engines (though in reality Chrome is just as different from Safari as the rest). Each of these families released different versions of their browsers resulting in a pretty wide area of browsers to support. This growth will probably continue in 2010, if not by as much as in 2009.

There is no real browser war like there was before, but it is obvious that these people are competing with each other. Implementation of the newest development techniques (css3 and html5) became a big thing again, luring the eager and bored front-end developer to start experimenting with these new options. This made 2009 a pretty interesting year, though also one of large frustrations.

was it progressive enhancement or graceful degradation?

Two other important concepts are progressive enhancement and graceful degradation. Both deal with catering for browser-specific audiences, making sure each and every person gets the full functional experience, but also providing the best possible solution for each separate browser version. Combined with the wild growth of browser versions over the year, this has made our job a lot more complex.

Certain new techniques are "available" to us, today. We can start using html5, we can do rounded corners in css, we can use web fonts and natively embed video. All these techniques feature a lot of "if"s and "but"s with different implementations for specific browser families and versions. If you want to use web fonts, you have to provide four (4!) different kind of font files and a pile of css for it to work. Go figure.

Rounded corners feature a similar problem. None of the browsers today follow the official standard (which doesn't even exist yet). There's a syntax difference between Safari/Chrome and Firefox, a rendering difference between Chrome and Firefox/Safari, no support for Opera (and no way to fix it) and a fallback method for IE. How terrible does that sound?

2010 and how to deal with it

Let's face it. IE will be lagging behind for quite some time. IE6 will still be there by the end of 2010, so how are we as front-end developers going to deal with these browsers, especially when 2010 will undoubtedly bring his own share of innovations for newer browser versions (a good friend of mine showed me an article on html5 forms, great stuff).

Adopting a new technique is doable, but adopting all these new techniques is just too demanding for commercial projects. Especially when we're still providing the time-consuming fallback methods which also work in newer browsers. Sure, designing for the future is a good thing, but not at twice the cost for a simple website. For example, it is perfectly possible to do rounded corners with (almost-)css3 for Firefox and Safari, leave Opera users in the cold (though the new version of Opera will support it) and provide images for IE users.

This is indeed faster for modern browsers (which are faster already) but a tad slower for IE (which needs to load the base css and the IE specific css). And the image solution still yields better results in Safari and Opera. So why go through the extra trouble to provide slightly faster (but not-standard) code for Firefox and Safari?

conclusion

If you look back at the hottest techniques of 2009, you'll see that almost all of them feature fallback methods and require more than one true standard to work. If you want to use web fonts, you have to stick to a different standard for each browser family. This is simply wrong, but on the other hand web fonts beat Cufon and sIFR to a pulp.

I'm still not sure how much I should adopt from these new methods. I'm eager to use new technologies. Ones that work faster, that are more logical and indicate the way of the future. But I also think it might be better to wait until they turn into a respectable standard before using them in any commercial project. It's not an easy choice to make, certainly while others are jumping on the boat already, gaining experience in what might be the techniques of tomorrow.

A very tough decision if you ask me. Opinions and input is always welcome!