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.
Imulus® is a technology focused design + interactive agency. 
XML sitemaps are a default for Web development at this point, yet I’m amazed about how many sitemaps are done improperly because developers use sitemap generators which either return partial or inaccurate coding. For the longest time we used 
