3 simple examples: why Internet Explorer 8 disappoints web developers

have me concerned that there’s a growing and false notion that IE8 is just great, and its rendering problems are the result of web developers writing non-standard code optimized for IE7.

To understand why IE8 is a legitimate disappointment, we need to start by providing background on how different browsers impact web development, both from a cost and design standpoint. If you think you already have a handle on this, you can skip ahead to our 3 straightforward examples of IE8 disappointments.

Background: Why Different Browsers Matter

In our world of web development, there’s plenty of inside baseball ranting about “inconsistent support for web standards” among the major web browsers: Internet Explorer, Firefox, Apple Safari, and to lesser extents, Opera and Google Chrome. Essentially, inconsistent support for standards means that when professional HTML and CSS developers turn graphical storyboards into actual web layouts, they encounter inconsistent and problematic results when reviewing the same code in different browsers, even when strictly obeying modern standards.

To make matters worse, catering to browser market share can mean catering to an 8 year old browser, released before some of the best standards were even drafted (I’m looking at your Internet Explorer 6, and your 25% share).

Professional web developers work around inconsistent standards support in two ways. Well, two and a half ways.

When it comes to the modern browsers (IE7+, Fx2+, Safari 3+), we 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. As a result, if the design calls for a heading with a shadow, we have a choice: spend time and money creating (and maintaining) images for all of these headings, or walk back the design. Either approach is a degradation in potential value. 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), and most of those special lines of code do not conflict with each other or add significantly to the code’s heft (as we’ll discuss in our translucency and rounded corners examples). 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, so long as it does not seriously degrade the user experience (while providing some value for 75% of the audience).

For example, if a WordPress administrator looks at the admin console from within IE6 or IE7, you’ll notice that the containers have sharp edges, which appear rounded in Firefox and Safari. As we’ll discuss, Firefox and Safari support a rounded corners style that makes it quick and painless. Adding rounded corners to IE6+ is considerably harder, and really, the cost of this value-add is not in sync with its end user value.

3 concrete examples of how IE8’s “behind the times” standards cost time and quality

Here are three very simple examples of standards IE8 still does not support, and what they mean for cost and design potential.

1. Rounded corners made simple

The first example is a favorite, because it’s a perfect illustration of a feature that can be added very quickly and easily in current versions of all major web browsers except IE8 and earlier, with a time consuming “lowest common denominator” solution.

Example of rounded cornersTo the right, you can see an example of a sidebar element from a site currently in development. Notice the rounded corners, both around the containing box, and the box heading. With Firefox, Safari, and Chrome, we were able to use the “rounded-corner” attribute (using non-conflicting browser specific attributes to ensure rendering) to do this quickly, and in a way that is easy to maintain. Here’s the CSS for the containing box:

div#sidebar div.module {
    margin-bottom: 13px;
    padding: 3px;
    border: 1px solid #939393;
    -moz-border-radius: 5px;
    -khtml-border-radius: 5px;
    -webkit-border-radius: 5px;
    border-radius: 5px; 

We specified a general border style; 1 pixel thick, solid (as opposed to, say, dotted), and with a hex color of 939393, which is a shade of gray. To give it rounded corners, we specified a “border-radius” of 5 pixels. As we indicated, we included browser specific versions of the border radius property (i.e. -moz- for Mozilla Firefox) to ensure compatibility with some versions of those browsers that included their own implementation of rounded corners before the formal standard was finalized.

For the heading, we did something similar, and added a 1 pixel wide x 25 pixels tall background image (the gradient dark to light gray gradient), and had it repeat horizontally.

div#sidebar div.module h3 {
  color: #fff;
  font: 1.4em Tahoma, Geneva, sans-serif;
  background: transparent url(images/sidebar_h3.gif) repeat-x;
  -moz-border-radius: 3px;
  -khtml-border-radius: 3px;
  -webkit-border-radius: 3px;
  border-radius: 3px;
  height: 25px;
  line-height: 25px;
  overflow: hidden;
  padding: 0px 10px;

Border Radius - not in IE8To the right you can see what this looks like in IE8 (and earlier).

In this specific instance, the  client decided it was not worth the extra expense to provide rounded corners to IE users. There are a few different approaches we could take, had we chosen to cater to the lowest common denominator. All of them, effectively, involve cutting up images with rounded corners. Below you can see one rough illustration of how we might have approached that.

Rounded corners using images

Whereas the CSS approach probably would have taken a few minutes to create, and a few seconds to tweak or change later, the IE approach takes many times longer to piece together, and nearly as long to make any notable change. And Lord help you if you need to make changes and you lost your source image files!

Those of you using IE right now, take heed. Expect more web developers with cost-conscious customers to “cut corners” (pun intended) with IE, and slightly degrade your experience.

2. Achieving some overdue font diversity

The biggest disappointment of creative designers everywhere is the lack of support for anything other than a handful of standard fonts for website copy (outside of kludges like sIFR, or images, neither of which are prudent outside of some headings). Therefore, there has been some excitement around the recent emergence of a new style property, “@font-face”, that will allow developers to support almost any font type in the future (although I admit I can already anticipate the licensing abuses and headaches).

Safari already has support for this property in its current release, and improves support in the Safari 4 beta. The forthcoming Firefox 3.5 (at beta 3, still dubbed 3.1) also adds full support. Here’s what the style definitions might look like to set a font for the entire page:

@font-face {
    font-family: "Alaska";
    src: url("bralarc0.TTF") format("truetype");
body,td,th {
    font-family: Alaska;

Here’s how this looks in Firefox 3.1 beta 3 (what will become Firefox 3.5):

@font-face in Firefox 3.1 beta 3

And here’s Internet Explorer 8:

@font-face in Internet Explorer 8

Now, to be fair and honest here, Microsoft does support a limited implementation of @font-face (and actually has for a long time).

The first problem is that IE8 only supports the completely proprietary “Embedded Open-Type Fonts” (EOT) format, whereas everyone else uses the common “True-Type  Font” (TTF) standard as well as the “Open-Type Font” (OTF) PostScript standard. So frustration #1 is getting fonts into the Microsoft-only EOT format. Microsoft does provide a nightmare of a and IE8 opacity filters)

Why, exactly, this is disappointing

Productivity and economics, not necessarily today, but 2 years from now. It’s that simple.

As stated in the introduction, catering to the lowest common denominator means either taking more difficult approaches to product realization (time=cost), or removing desired features, at least for a portion of the audience (value reduction). Rounded corners is a great example of either possibility, and the font type is a great example of the latter. And remember – there are many more examples; these are just 3 of the most practical and concrete use cases developers like us deal with almost every week.

Now, regardless of fixes for issues like translucency, IE8’s impact in the short term is minimal. If you believe the statistics, IE users are the least likely to upgrade quickly anyhow (I suspect this is because most of the share, particularly of IE6, comes from business computers and slow to upgrade IT departments). IE6 and IE7 are a reality in our web development lives for the immediately foreseeable future.

What’s most disappointing is thinking about where we’ll be in 2 years.

The 6+ year stagnant development cycle between IE6 and IE7 was an understandable if regrettable consequence of their dominance of the web business, after driving Netscape out of business. 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.

We hope that Microsoft doesn’t wait another 2 years to build on IE8. Perhaps IE8 represents a baseline for a rebuilt underlying engine, and they can push out “point” updates (IE 8.1) more quickly that add better and more modern standards support.

That said, right now, far from being an innovator and challenger in the web space, Internet Explorer has become a hindrance to progress. I’ll go out on a limb here – if they just can’t keep up with the folks behind WebKit (the Chrome/Safari engine) and Mozilla (Firefox’s engine), maybe it’s time to abandon their own rendering engine and adopt an open platform like WebKit themselves.

8 Responses to “3 simple examples: why Internet Explorer 8 disappoints web developers”

  1. James Burton says:

    Non of these are fully signed off “standards” so to question a browsers dedication to standards compliance on this bassi is flawed microsoft bashing. The Acid2 tests are a great example of how far IE8 is ahead of IE7, and the simple inclusion of “Compatibility Mode” allows IE8 to move towards better standards compliance without writing off sites written with IE7 as a target. Please get off your high-horse and acknowledge the improvements that have been made more honestly!

    CSS3 will add various things like rounded corners, but until it’s standards are agreed then bashing non-compliance is a deluded misrepresentation! The simple practicalities of trying to provide a consistent browser, rather than a constantly patched and updated browser like open source offerings, is not appropriate for supporting non-standards that may be agreed in the future. You have to also include that firefox users may not install every update, at which point the firefox support for these issues is not 100% either, and the same pretty well applies across all other browsers. As a web developer I’d rather have more fixed targets with strong version levels than trying to support suggested features and having to explain the difference between Firefox 3.0, 3.1, 3.1.2, etc. and ensuring that all users are supporting the latest micro-version of a browser for some new feature!

  2. Jake Goldman says:


    Thanks for your input. I’ve approved your comment in the interests of engaging discussion (which I welcome) on the subject. In the future, please avoid personal attacks on my “honesty” if you want your comment to be published (”deluded”, “high horse”, etc).

    While it’s true that CSS3 is still technically a “draft” spec, there’s really no question as whether styles like “opacity” and “border-radius” are going to be formalized. Saying Microsoft should avoid these specs is really as ludicrous as suggesting that Cisco should avoid compatibility with the N-wireless spec since it’s not yet formally ratified.

    In any case, I think you’ve missed a key point.

    No one denies that IE8 is a step forward in terms of, really, the *minimum* standard any browser should be expected to meet (CSS2). The point is that Microsoft seems to update their browser on a 2+ year life cycle. Having to wait 2 more years before we web developers can use great CSS features like border-radius, font-face, and opacity is, as the title suggests, disappointing. There is nothing innovative about IE8 (can you name one new development innovation?).

    As a web developer I’d rather have more fixed targets with strong version levels than trying to support suggested features and having to explain the difference between Firefox 3.0, 3.1, 3.1.2, etc. and ensuring that all users are supporting the latest micro-version of a browser for some new feature!

    Let’s note that Firefox and Safari, as examples, have supported properties as basic as opacity for several versions now. These are not “micro-version” features.

    Rafael Rivera, a well known and respected Windows writers and enthusiast made this comment in response to some discussion on my post over at a Winsupersite, and I think it sums up my point quite nicely:


    Going into your article, I was so sure you were just another web developer bitching about bleeding features not present in Internet Explorer… but refreshingly, I was wrong.

    I think we can all agree Internet Explorer 8 is a big step in the right direction in terms of standards support, but 2 years from now, like you mentioned, it’ll be around — stifling innovation. Yet again.

    That said, word is Microsoft will be trashing Trident and going either Webkit or Mozilla. Hard to swallow right now, I know. We’ll just have to wait and see.

    That’s the point.

  3. mtness says:

    Hi there!

    Concerning opacity, what about:
    -moz-opacity: 0.8;
    opacity: 0.8;

    looks okay to me?!

    Kind regards,


  4. IE8 sucks says:

    IE8 sucks big deal. Of course it is better than IE7 but there is no way we can say that IE8 is better than Safari, Opera, Google Chrome or FF. In my opinion FF is still the best followed by Google Chrome. Another piece of #$%@ produced by MS. Have said that, I think that Internet Explorer is the Vista of Web browsers.

  5. Atul says:

    I know this is off topic but you seem to know a lot about cross browser compatibility
    so could you help me use rounded edges which would run on all browsers.

  6. Jake Goldman says:

    Atul – the only way to do rounded edges in a cross-browser way is to use images for the corners. There’s more than one way to skin this cat, but essentially, you’ll need an image at the top, and an image at the bottom. Absolute positioning two images in a relatively positioned box (bottom: -1px, left: -1px and top: -1px, left -1px to account for the border) is the way to go.

    If you want us to help you implement a layout with rounded corners, use the “request a quote” button!

  7. David says:

    Very good analysis.

    Although the developers of IE8 appear to be intent on making IE as good as it can be, I still doubt that senior management have fully given up on the “embrace, extend and extinguish” mentality – http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

    Also, it’s worth remembering that if it weren’t for a massive outcry from web developers, MS would have made IE8 standards-compliant only with inclusion of a proprietary switch in your code – bizarrely and wrongly supported by Zeldman.

    P.S. Kudos on allowing the first aggressive and rude comment. It’s curious the way some people attempt to defend in the indefensible.

  8. Jake Goldman says:

    David – thanks for the feedback.

    There’s no doubt that IE8 is a step in the right direction. While I’m pleased that they’re *more* aggressively enforcing standards, considering this praiseworthy feels a bit like complimenting the misbehaving child for finally engaging in the minimum acceptable behavior.

    There’s some indication that we may not have to wait another 2+ years for an upgrade. Apparently Microsoft is already publicly soliciting feedback for IE9 development. Let’s hope it’s a sign that they’re moving quickly.

Leave a Reply