Skip navigation

Why Internet Explorer 8 disappoints web developers

Jake Goldman has written up a lengthy post using three examples of how Microsoft continues to disappoint web developers with IE 8. I think this is an important part of the overall discussion around this browser, and about browsers in general, and of course the wider uber-topic under which it all sits, our inevitable migration to cloud computing. I've given IE 8 a very positive review, something I was pretty sure wouldn't happen as recently as two or three months ago, but in using the browser over a long period of time, I've come around to the notion that IE 8's security/privacy and "beyond the page" (Microsoft's phrase) features will make a much bigger difference to users (real users with real concerns, that is, not people concerned with niche side topics like the Acid3 test or whatever) than various technical failings (or its performance, though I think that's an important concern as well).

None of that should take away from the message of this post, however, which seeks to develop "a deeper understanding of the strategic, cost, and technical significance" of IE 8. Again, it's a topic worthy of debate.

When it comes to the modern browsers (IE7+, Fx2+, Safari 3+), web developers mostly cater to the lowest common denominator. For example, Safari supports on the fly rendering of font shadows, but IE7 and Firefox 3 do not ... The most infamous example of design / browser trade off is font type, which we’ll discuss in our examples.

Alternatively, developers can write alternative code based on the user’s browser. With the “modern” browsers, there are only a few reasons to do this (at least for capable developers) ... In the case of one IE6, however, there are so many inconsistencies and glitches that almost every site we develop has a special stylesheet only for IE6 users. It goes without saying that this adds time (=cost).

The “half way” is not so much a way of addressing the differences as it is a way of accepting the differences. That is, the notion of “failing gracefully.” The idea here is that if a browser like IE6 simply can’t support a non-critical feature (a “nicety”) without significant additional cost and effort, we may elect to leave a feature out.

Goldman then supplies three very specific examples of where IE 8 falls short.

One is CSS-based rounded corners, "a feature that can be added very quickly and easily in current versions of all major web browsers except IE8 and earlier." I note that this feature requires "browser specific versions of the border radius property" for Mozilla, KHTML, and WebKit, but whatever. IE renders the graphical box corners as non-rounded.

The second involves fonts. He notes that there is "a new style property, @font-face, that will allow developers to support almost any font type in the future." It's not fully supported in any shipping browser, however. It works somewhat with Safari 3 and will apparently work fully in Safari 4 (now out in very early beta) and in Firefox 3.5 (now in Beta 3).

The third issue involves opacity, or "support for translucent / semi-transparent / opaque / whatever-you-want-to-call-it elements, particularly backgrounds." Today, "the latest stable version of Safari [Safari 3? Or is Safari 4 the latest 'stable' version? --Paul], and the forthcoming release of Firefox 3.5 would make semi-transparent backgrounds even easier with support for a 'RGBA' (or 'Red/Green/Blue/Alpha') value for the background property." It's not supported in IE 8.

OK. Obviously, there are many more examples, presumably some of which relate to every other browser on the market aside from IE. (Which, by the way, still controls about 70 percent usage share.) The main argument seems to boil down to this:

With serious competition from Firefox, Apple’s Safari, and now even Google with Chrome, there was hope that Microsoft would be far more aggressive with IE8. The hope was that this aggressiveness would push the browser makers to standards oneupmanship (which we are getting from Apple and Mozilla), resulting in platforms and market share that, 2 years from now, would erase many of the obstacles web developers face in pushing design and development value to their limits.

So, what he's not taking into account here is the unbelievably aggressive change Microsoft actually is making, and asking its one billion customers to make, with moving to an on-by-default, standards-rendering mode with IE 8. This is going to be a huge issue for millions of people, far more people than will ever be affected by the picayune little web development issues he raises here. While I wish on some vague level that Microsoft would "adopt web standards fully," the truth is that life is more complicated than what he's presenting here.

And let's face it. Who really cares how hard life is for a small group of people (web developers)? Do your job, for crying out loud.

(In interests of fairness, just raising this issue is of course part of doing the job. But there is a "blame Microsoft" mentality that's so easy to fall into. Where is the praise for moving so aggressively towards web standards?)

I do agree that Microsoft needs to push out IE updates more quickly than with the next major browser release (IE 9?). And maybe now that Microsoft has finally made the first tortuous step, it can gauge reactions and then start delivering those updates (to CSS, HTML, whatever) once the dust settles.

There's a lot to think about here, and I don't want anyone to believe I'm dispensing with this as an issue. I'm not. This is worthy of thought and debate. But let's not forget that to the average user, and that's most of them, IE 8 is a huge step forward. It's not as big of as step as it could be if Microsoft didn't have all those existing customers to worry about. That, as in many things Microsoft, is always the central issue when it comes to forward-looking innovation attempts.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish