On a daily basis I spend anywhere from five minutes to three hours cursing and wishing ill will upon Microsoft Internet Explorer 6. Sometimes I do this silently under my breath and sometimes, to the dismay of my coworkers, I do it quite vocally. The reason? Internet Explorer 6 is an: insecure, slow, outdated, and non-standards compliant browser.

Let me illustrate this a bit further. If browsers were cars — IE6 would be an El Camino truck that’s been sitting outside in the rain for 20 years. Underpowered, ugly, basically useless in every scenario, and ready to explode and kill you at any moment.

Development of a website that supports IE6 adds about 15 to 20% of additional time to a project. And further, IE6 doesn’t support the everyday commonplace technologies of all other modern browsers. Meaning websites simply don’t function or look as good as they do in today’s browsers.

So here’s the question.

If today’s modern browsers (Firefox, Safari, Chrome, Opera, IE7) are easy to get, run faster and safer than IE6, and are free. Why are some company IT departments still forcing users to browse on IE6? In general it seems to boil down to three big reasons.

1. The company has internal software that was built specifically to run on Internet Explorer.
2. The company manages a ton of machines and the workload/headache of upgrading them all to a newer version is too much.
3. The company and users feel comfortable on IE6 because they “know it”.

Here’s the problem. When we as an industry don’t embrace new enhancements in development it’s the client’s viewers and the client’s brand that suffers. We’re still building phenomenal web sites. But the straight truth of the matter is they’re not as good as they should be. The web has soooo much potential but it’s not being utilized. Why? Because we’re still supporting a legacy browser* that was released in 2001.

As I’ve said before. In order for things to get better sometimes you just have to make the jump. Other companies are already doing this. Apple, 37Signals, and Comedy Central just to name a few. Notice anything about those first two? They dramatically care about their user’s experience. So much so that they’re willing to sacrifice incompatibility for some users to benefit the rest of them**. Cheers to that, I hope we see it more.

^{* As long as companies ask us to support IE6 we will. We’re not afraid to share our thoughts on the browser landscape but we also recognize the need to compromise.
** I understand that some users don’t have control over what browser they use. For these poor souls I cry (really, I’m tearing up as write this).}

This past week while working on a project I ran into the most frustrating IE7 bug I’ve encountered to date. I have tried to recreate it in separate environments from the site I was developing but up to now have been unable to do so. However, in hopes of helping someone tortured by this bug down the road I will give my best guess as to what is causing it and explain how I fixed it.

First off, the bug looks like this:

Alright, the first thing is that this bug comes into play only in IE7 (IE6 works fine). Second, it seems to occur only when there are html elements nested inside an anchor tag and these elements are told to change their background properties on the :hover phase of a parent element. This most often happens with nested list drop down menus like the example above. Third, the elements that act buggy are positioned absolutely within the :hover(ed) parent element. Once again this only really occurs with drop down menus.

In the code below the element that gets the bug is the anchor element within the nested list items.

<div id="navigation"><ul id="nav">
<li><a href="" title=""><span>Solutions</span></a></li>
<li><a href="" title=""><span>Investors</span></a><ul>
	<li><a href="" title="">Buggy nav item 1</a></li>
	<li><a href="" title="">Buggy nav item 2</a></li>
	<li><a href="" title="">Buggy nav item 3</a></li>
</ul></li>
</ul></div>

What happens is that when a top level navigation item is hovered over the drop down appears, however, because a top level nested element had a background image change on the :hover state the drop down list loses its padding. In essence, the ul > li > ul > li > a element will lose its padding and end up looking like the buggy menu above. Although once the user rolls over this anchor element it will once again regain its padding and jump back into place.

When would this occur?

Good question. The most likely occurrence of this would be if you had a navigation menu that required a lot of imagery. For example, a menu with which you were forced to use a span tag to get one extra background image. And then on the hover you wanted the span background image to change, perhaps to point an arrow downward instead of sideways. Therefore the user would know which top level item they had hovered over even if the mouse was placed on the nested sub-menu below. In this case you’d probably have some CSS like this.

#header ul#nav li.active a span,
#header ul#nav li:hover a span {
   color: #fff;
   background: url(/images/icons/downward-arrow.gif)
   no-repeat 15px 50%;
}

Alright, so basically you decide to help the viewer see what nav menu they’re on by changing the span background property to have a down arrow. Unfortunately all you end up with is a buggy IE7 drop down menu. What’s the best fix? In this case the best fix is the apply that downward arrow to the li background and just have the span item go transparent instead of change the image on the fly. One added bonus to this method is that you won’t have to load that image on the hover state. Still, this means that if you’re using the li background already you will be forced to find another way to highlight the top-level navigation item.

What’s really going on here?

Apparently when IE7 tries to re-render a background image on the :hover state, nested absolutely positioned elements are reset to their default value causing them to lose padding, etc. Hence, the best option is to avoid making IE7 redraw background images when there are absolutely positioned nested elements. Instead, rely on background colors or transparency for effect, or apply the effect to the li background.