I’ve yet to hear back from Microsoft regarding the IE7 bugs, so I took matters into my own hands and have found out what’s causing the majority of the bugs and how to work around them.
It’s all about hasLayout. This is the best review of all things related to hasLayout and this is Microsoft’s take on the situation. These two documents will give you everything you need, and more, to understand what might be the source for the vast majority of IE-related layout bugs.
And so it is no surprise that it is the source of my problems as well.
Menu 1 & 2 in the demo have specific widths set on the LI elements. This triggers hasLayout on the LI elements. Menu 3 has no specific width set on the LIs and thus they do not have layout. 1 & 2 display gap, z-index, and visibility bugs, 3 does not exhibit any of those bugs.
But menu 3 has a new bug. Mouse through the top-level menu and you’ll see the content below the menu moves vertically a few pixels. This doesn’t happen in menus 1 & 2. What’s going on?
( Nevermind the lack of side borders. That’s less an IE bug and more a poor management of applying negative margins to have elements overlap. I fix that in menu 5… but we’re getting ahead of ourselves. )
Menu 4 is an exact copy of Menu 3 with one exception:
zoom:1; is applied to the anchors inside the LIs. The vertical jumping disappears. This means triggering hasLayout on the anchors fixes the text jog.
Menu 5 is a (relatively) bug-free implementation working in IE7.
But there’s one problem left. When the menus pop over text and you mouseover the menu that’s over a text block, the menu disappears. Actually it’s when you mouse over the text and you’re outside an anchor (hasLayout strike again!) such as the border between menu items (which is on the LI element).
So maybe I need to draw borders on anchors and not list items. I know I had a specific reason why I didn’t want to do that, but I’ve forgotten it. Guess I’m going to rediscover why.
So there you go. Some headway in the rMenu saga.