Degradation Without Grace

Web developers are spending a lot of time applying workarounds for technically obsolete browsers. This is causing high development and maintenance costs for the web industry.

IE7 was a step, but only one step, in the right direction. For IE6 and IE7, the extra costs of developing a web site are currently justified by IE’s combined market share, not because it makes sense technically.

A significant amount of companies are locked in due to their process dependencies. Huge applications were designed for IE6-only, not with standards in mind. They cannot simply update to IE8, even if Microsoft is moving into compliance with the web standards for their new browser.

Microsoft has, therefore, implemented a compatibility view button, so users can surf their company’s intranet with IE7-like behavior, and surf the web with IE8’s improved rendering (if the page is ready for it). Sadly, that won’t solve the locked-in-IE6-trap.

Therefore, support for IE6 cannot end, at least for sites with such a large and diversified user base as XING has. It doesn’t matter how fast the market share of IE6 decreases — the absolute numbers are too high in years to come.

But we, workers in the web dev field, dare we question some certainties of our métier? Neither the concept of progressive enhancement (modern browsers bring the best out of a page) nor the concept of graceful degradation (inferior browsers do leave an acceptable impression at least) prevented the messy situation that we are in.

Maybe we have hit a dead end.

If we name everything that is needed for IE to approximate a standards behavior a hack, then it must be admitted that we practice vast presentational hacking. The rendering has to be pixel exact with regard to the photoshops and expectations of our co-workers, and these expectations are projected with ease onto our clients.

Isn’t it ironic that we, as web developers, have made this nonsense possible? It is our documentations and analyses of browser bugs. We, not the vendors, did that. We found workarounds for today’s complex pages in IE, or, if this failed, we reverse engineered its bugs for standards-compliant browsers so they act like IE. So we made this trap for ourselves, conscious of the consequences or not. IE has been code-frozen for many years — same as the web development process in our heads.

The current paradigm: A page has to look equal in all browsers, that is, like in IE6. We stopped thinking about how ineffective this is and how much the performance of a site is slowed down.

To be honest, there was never an identical user experience for IE6 users, compared with users of modern browsers.

The web is about information, networking, and interaction. This means, a page simply has to work. As I see it, disgraceful degradation would abandon the attitude of everything-is-possible. Functional hacking should supersede the obsolete presentational hacking now, or we keep being trapped in a costly, mutual mistake of the web developers and the web consumers.

We understand the fact that IE6 cannot be updated immediately, and to be clear, we will make strong efforts that a page does work in IE6 with a rich user experience. However, it is not set in stone that a browser of 2001 should display the page equal to recent browsers like Chrome, Safari, Opera, Firefox, and IE8.

It’s just a pixel less here and there, not a revolution.

About the Author

This entry was posted on Friday, February 20th, 2009 at 10:47 and is filed under Frontend. You can follow any responses to this entry through the RSS feed. You can leave a response, or trackback from your own site.