Internet Explorer 8 is out, and a lot of people – technically sophisticated and otherwise – are wondering what, if anything, this means for the web. As professional web developers, our view is that while Internet Explorer 8 is an incremental improvement over its predecessor, we’re mostly disappointed by its lack of progress.

Having read a variety of takes on IE8, we were inspired to write this article for two audiences. First, there’s little in the way of concrete examples and clear explanations for a large swatch of the business technology decision makers (that many of our clients represent) who are often savvy about technology, but look to organizations like us for a deeper understanding of the strategic, cost, and technical significance. Second, reading the comments on tech savvy websites like Neowin, Digg, and the Winsupersite 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 tool to get  TTF into EOT. The tool does not support OTF, however, and there’s no easy way to get OTF to TTF either.

Assuming one doesn’t give up during the conversion process, here comes frustration #2: because IE8 does not correctly support the CSS property, one cannot (as they can in other browsers) just provide a comma delimited list of fonts, including both the EOT file and TTF file. Critics of IE proprietary styles (as a supposed cause of IE8 issues) take note – to achieve custom font faces in both IE8 and with every other browser, one has to write special, IE-only code that overrides the previous (standards compliant) @font-face value.

What’s the impact here? Developers can incur more cost implementing a non-standard IE specific solution, can choose to let IE fail gracefully over to the closest standard font, or (very likely in many instances) will continue to ignore the possibilities of diversified font types for the foreseeable future.

(more on cross browser @font-face support)

3. Opacity / alpha channels

Support for translucent / semi-transparent / opaque / whatever-you-want-to-call-it elements, particularly backgrounds, has a lot of obvious use cases. We frequently use a translucent background effect in fly-out navigation bars. Likewise, there are good use cases for elements on a page being entirely translucent; backgrounds, content, and all.

Translucent backgrounds aren’t that painful, mostly because we “cater to the lowest denominator” and use a semi-transparent PNG background image (1 pixel x 1 pixel repeated) to create the effect in a way supported by all the major players except for IE6. In that case, we “fail gracefully” by providing a solid, non-translucent background (which, before anyone brings it up, we find superior to a well known JavaScript hack that tends to wreak other kinds of havoc in complex sites).

The latest stable version of Safari, 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. So, if I wanted to give an element a red background color with 50% transparency (alpha), I could simply set its style like so:

<div style="background: rgba(255, 0, 0, 0.5);"></div>

Easy to change and maintain, easy to implement. But not supported even in IE8. Looks like we’re stuck with background images for a long while.

But that’s not the worst of it. What if we want to make an element completely translucent; background, content and all?

Earlier, we mentioned that there are often properties or lines of code that are browser specific, but are simple and do not conflict with one another. Browsers compliant with modern standards, including released versions of Firefox and Safari, support the “opacity” CSS attribute (opacity: .5;). IE7 (and IE8) will ignore this style, but (with some exceptions we won’t get into here) we can add an IE7 specific style (filter: alpha(opacity=50);) that would create the same effect, and be ignored by other browsers.

However, in the new (and default) standards mode in IE8, that IE7 code is ignored. And IE8 still doesn’t support the simple “opacity” standard. Microsoft has given us a new way to achieve this style, and here it is in all its beauty:

-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";

I raise this example particularly because it’s a good case of the “IE8 rendering problems [coming from IE7] are a result of web developers not building their browsers to standards” myth.

Maybe by IE9 we’ll get “opacity”, a CSS 2.1 standard (we’re up to document standards for CSS 3, by the way), so we won’t have to update again.

(further detail on RGBA 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.