New Guillotine case in Internet Explorer (IE7)… Or not!

Yes, it's a fact that Internet Explorer 7 is better than Internet Explorer 6. But not all squashed bugs were completely killed. Like the little gopher game you play at the fair, sometimes when you bang one on the head and it goes underground, it simply pops back out in a different place. Enter the Guillotine Bug.

Yes, we all hoped it was dead and gone. But by finally supporting some of the previously unsupported properties, new cases have evolved. I had one on my own, freshly launched site recently. Today, I took the time to figure out what was going on. Since it was a bit odd, I thought I'd share it here in hopes of helping someone else since I found nothing in Google exactly the same.

Since IE7 now supports the :hover pseudo class on non-anchor elements, I decided it would be nice if the whole list item in my sidebar changed background color on hover. I placed a different background color and a completely different border effect on the li:hover selector. Within this list element was a left-floated icon and static h3 and h4 elements (which are links). It worked perfectly in IE6 and earlier, Firefox, Safari, etc. But IE7 decided to hack a hairball. When you hovered over either the h3 or h4 link, the bottom half of the floated icon disappeared. If you have IE7, I put an unfixed demo page (from my site's contact page since it has two sidebar items with links and one without) up to test with. If you don't have IE7, there's an image for you to view to the right of this paragraph. Problem is, though it looked just like the guillotine bug in IE6, the usual necessary elements weren't there. And IE6 was fine.

The old Guillotine

With the old guillotine bug, as with most bugs, there was a list of ingredients needed (listed from Position is Everything):

1. A container element (This was my list element)
2. A float element inside the container that is not "cleared" (this was my icon)
3. Links inside the container in non-floated content after the float (both my h3 link and h4 link followed my floated icon – check!)
4. a:hover style rules for those links that change certain properties (ooops! This is where the recipe goes wrong. The links following the floated icon did NOT change any of the necessary items which are:
   • Background
   • Padding
   • Text Style
   • Border etc.
5. Internet Explorer, obviously (got this one)

The initial troubling fact to me was that the old fixes for the guillotine didn't work. It didn't help at all to clear or contain the float. But then, this guillotine wasn't classic either.

The Newly Uncovered IE7 Guillotine

No doubt, other guillotine variations will be or have been uncovered–and I say uncovered, and not discovered, since this issue was probably already there–but due to IE6 and earlier not supporting hover pseudo classes, it simply wasn't revealed. In my case, it appears that creating support for hover on a pseudo class, but only fixing the currently documented guillotine bugs, let some new cases slip through the cracks (come to us IE8! ). This bug, rather than being related to the hover on the links following the float, was related to the hover on the li element itself (parent container). I've not tested it, but it would be logical to see this happen within other parents, like div and p elements.

The fix was the usual fly swatter–hasLayout. Some of the ways I tried to fix it had untoward results–position: relative; and min-height: 0;–both caused the top border on the li to disappear–whether separately or in combinaton. I think display: inline-block; would actually have worked, only it took me a bit to realize that the margin-top: -15px on the "#sidebar1 li h3" (obviously there because hasLayout was needed) had to be removed. That done, all was well in IE7's world.

7/12 Amendment–Background Painting Bug?

I've been talking back and forth to Alan Gresley about this bug since he's been documenting new IE7 bugs. We've come to the conclusion that this isn't actually a true guillotine, but instead, is the overpainting of the float with the background on an element without layout. Specifically, the li:hover changes the background color, and when it does, it overpaints part of the floated icon. When he gets the page uploaded to his site, I'll link to his demos showing variations and odd behavior. Stay tuned…

Meanwhile, kinda makes you wanna just write an IECC with hasLayout for everything that doesn't, eh? Or wring IE7's neck (obviously that would be right below the crossbar of its e…) all while shouting, "buggy, buggy, BUGGY!"