Weblogs: Web Standards

A web developer's responsibility is to build a website that best delivers on the expectations of that website's target audience. Every decision about the website must always take that audience into account. You cannot convert a visitor into a customer without offering something of value to that visitor.

The browser support of your website must be directly correlated with your target audience. If it isn't, you are doing it wrong. If you still consider it to be a technical decision, you are doing it wrong. If you think that it is cost-prohibitive to support Internet Explorer 6, your development approach isn't conducive to the Web. You are doing it wrong.

The hostile environment

Douglas Crockford, the JavaScript Colossus, frequently notes that the browser is the most hostile programming environment imaginable (this was before he found out about mobile development!). This should come as no surprise to anyone developing on the Web.

And yet, each piece of the web development puzzle is actually quite simple and can be picked up and learnt in an afternoon. HTML, CSS, JavaScript, jQuery, progressive enhancement, Firebug/Charles, HTTP, Fiddler, Cookies, sessions, caching, redirects, accessibility, internationalisation, semantic markup, form submission, CSS sprites, CSS page layouts, Ajax, CSS & JS minification, analytics, supporting Firefox, Safari, Chrome, Opera, IE6 & 7 rendering issues. Nothing on this list is complicated, almost all of it is seriously documented and covered on the web.

Independently these are simple. The complicated part is handling all of that simultaneously while developing; recognising the overlaps and potential conflicts. Complex features on websites are collaborations of simple pieces.

Supporting Internet Explorer is just one little piece in our complex jigsaw. It needs to be handled with the same care and attention as every other piece. Internet Explorer 6 is special in its own unique way. This should not be news to anyone who builds websites.

Yes, supporting IE6 isn't quick and easy. But it's our job as web developers to support it as long as our engaged audience uses it. (Remy Sharp's pointed reply "What do you mean, you don't like IE6? Really?" is worth reading.)

Spewing bile against IE6 has turned into a seasonal perma-thread. Every few months another embittered developer decries his fate and begs the technical community to do something about it. I'm fascinated by the arguments of why IE6 needs to be euthenised. I realise that, as those arguments are expressed, they reveal a deeper problem: a lack of a disciplined approach to web development.

The secret of failure: Leaving it to the end

The main technical argument about why IE6 support needs to end is the cost of supporting it. The current iteration of this perma-thread is a Computer Science graduate who spent two days trying to fix his already built web site to work in IE6.

He openly admits supporting IE6 was an after-thought. He didn't consider it during the development process. Why not?

When something fundamental is added onto a project after the development is complete, how can we be surprised -- as technical people -- when the amount of effort to incorporate this new requirement turns out to be expensive and painful?

Accessibility. How often do capable technical people put forward the argument that accessibility is cost-prohibitive and would put many businesses into bankruptcy if the existing legal requirements were actually enforced? (Despite a perfect case study of the commercial benefits of being accessible.)

The expense of these requirements are not because these requirements are onerous. They are because these requirements were not considered upfront as requirements and verified during the development process.

Why isn't IE6 support considered up-front at the start of a project? Why isn't a web developer asking the IE6 question at the start of the project? Can a web developer really be oblivious to Internet Explorer 6's existence and special needs?

Leaving any requirement untouched until the end of a project is asking for trouble and pain. The fault isn't in the requirement, but in the developer's approach to web development.

Forgetting IE6 exists is not an excuse for a web developer. Keeping quiet and hoping that a product person doesn't later add it as a requirement is unacceptable.

A line item on an invoice or quote detailing "Internet Explorer 6 support" is subtitling the main delivery as "couldn't build it properly the first time".

The web development process

The approach to dealing with Internet Explorer 6 is obvious. Document the support of it at the start (based on your target audience). Define what that support means. Test and verify that support as you develop incrementally.

Support isn't a binary option. It ranges from pixel-perfect rendering, to slight differences in rendering, to completely working with a simpler style, to providing only the core functionality, through to zero support at all. The right level is that which matches the enagement of your audience using that particular browser.

Typically, your site analytics will identify the browsers used by your visiting audience. This provides a useful starting point to build on. Although, don't get caught out making decisions on those stats if your exisiting site has issues and problems for the browsers you are considering support for. Obviously if a site doesn't work in Firefox, the conversion rate for visitors using that browsers will approach zero and distort the actual engagement of that portion of your audience.

Every new feature you build, every line of code you touch, adds a new set of assumptions. You need to test those assumptions while they are fresh and malleable. You need to correct those assumptions as early as possible.

Your development environment should support the regular testing of your code in multiple browsers. If your development environment doesn't allow regular testing of your code in IE6 & IE7's Trident renderers, a Webkit renderer, a Presto renderer, and a Gecko renderer you do not have a suitable environment to do web development.

As each layer of functionality is added you should be testing in several browsers used by your audience. Doing the bulk of development testing in only one browser is unacceptable, and obviously flawed. You know that IE6 and IE7 aren't at the quality levels of modern browsers, so you have no excuse not to be regularly testing in them.

Engineers and computer scientists understand the benefits of a structured approach to development and the benefits of tested and reusable code. The principles of high-quality software engineering apply just as well to high-quality web development.

Self-harm is a cry for attention

If you leave IE6 testing and fixing to the end of your project, you have no-one else to blame for the pain but yourself. This is part of your job as a web developer, do it properly and to the best of your ability.

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]