C. Murray Consulting - Web Development and Strategy Experts located in Providence, Rhode Island

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.

To 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;
}

To 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.

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):

And here’s 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.