After doing the majority of the work with the Sons of Ursidae menus, I was to discover from various CSS list while googling that there was an issue with sticky submenus with IE7 for most of the barebone examples of the Sons of Suckerfish menus. When a user left mouse clicks on the page and then hovers over the menu again, the submenus become sticky and do not go away when unhovered.
IE7 now has support for dynamic pseudo classes li:hover in most cases, but with the barebone examples of the Sons of Suckerfish menus, IE7 chokes on the CSS shown below.
#nav, #nav ul {padding: 0;margin: 0;list-style: none;line-height: 1;}#navs1 a {display: block;width: 6em;}#nav li {float: left;width: 6em;}#nav li ul {position: absolute;background: blue;width: 6em;left: -999em;}#nav li:hover ul, #nav li.sfhover ul {left: auto;}#nav li.sfhover ul {left: auto;}IE6 or IE5 don't understand dynamic pseudo classes so they needed some javascript and uses sf.hover which mimics the dynamic pseudo class, so the result in IE6 or IE5 is the same as for the more standard compliant browsers that support the CSS2 specifications for dynamic pseudo classes. IE7 however behaves in a much stranger way. Below is a example of the barebones Sons of Suckerfish dropdown.
Please use IE7 to see the bug. If you hover over the above menu and nothing happens, then you are using IE7 with javascript disabled. IE7 is not honoring this selector #nav li:hover ul for some reason. If the above menu works showing the dropdowns, then you are using IE7 with javascript enabled. Yes IE7 uses javascript for help as the CSS now stands. With javascript enabled, left mouse click anywhere on this page and then hover over the menu again. What you will see is the IE7 sticky hover bug. Refreshing the page, resets the sticky hover bug to its original state before the left click on the page. This is not an effect that is seen in IE6. For an isolated example, please follow this link for an example of the IE7 sticky hover bug
A few fixes for the sticky hover bug have appeared on various mailing lists or forums. This involves adding a new selector #nav li:hover to the CSS with either of these properties and values {height: 1%;}, {background-position: 0 0;} or {position: static;}. Even though hasLayout is not directly related, adding a hasLayout trigger or Reset hasLayout also fixes the bug. Even some old bug fixes, IE Pure CSS Pop Ups Bug for a IE5 and IE6 handling of pseudo classes work. Through experimenting I found some other bug fixes that use various methods. A table of the many bug fixes is below.
| Selector | Property and value | hasLayout |
|---|---|---|
| 1. Does not work with the Sons of Suckerfish Vertical menu. | ||
2. This property and value can appear on either the #nav li:hover and #nav li:hover ul selector. | ||
| 3. Background colour disappears. | ||
#nav li | {height: 1%;} | True |
#nav li:hover | {height: 1%;} | True |
#nav li:hover | {position: static;} | True |
#nav li:hover | {background-position: 0 0;} | Neither |
#nav li:hover | {position: relative;} [1] | Neither |
#nav li:hover | {background: green;} | Neither |
#nav li:hover | {height: auto;} [2] | Neither |
#nav li:hover | {border: 0;} [2] | Neither |
#nav li:hover | {margin: 0;} | Neither |
#nav li:hover | {padding: 0;} | Neither |
#nav li:hover | {text-align: left;} [2] | Neither |
#nav li:hover | {text-indent: 0;} [2] | Neither |
#nav li:hover | {white-space: normal;} [2] | Neither |
#nav li:hover | {visibility: inherit;} [2] | Neither |
#nav li:hover | {width:auto;} | False |
#nav li:hover ul | {zoom: 1;} | True |
#nav li:hover ul | {display: inline;} | True |
#nav li:hover ul | {display: inline-block;} | True |
#nav li:hover ul | {display: block;} | True |
#nav li:hover ul | {float: left;} | True |
#nav li:hover ul | {height: auto;} [2] | Neither |
#nav li:hover ul | {border: 0;} [2] | Neither |
#nav li:hover ul | {text-align: left;} [2] | Neither |
#nav li:hover ul | {text-indent: 0;} [2] | Neither |
#nav li:hover ul | {white-space: normal;} [2] | Neither |
#nav li:hover ul | {visibility: inherit;} [2] | Neither |
#nav li:hover ul | {float: none;} | False |
#nav li:hover ul | {max-width: none;} | False |
#nav li:hover ul | {min-width: 0;} | False |
#nav li:hover ul | {max-width: 0;} [3] | False |
#nav li:hover ul | {overflow: visible;} | False |
#nav li:hover li | {float: none;} | False |
The bug fixes that use the #nav li:hover ul selector do not work for the barebone examples of the Sons of Suckerfish menus with a second generation submenus, the selector which positions the second generation submenus in the barebone examples of the Sons of Suckerfish menus has to be changed because the second generation submenus don't show. Shown below is the CSS that is used to position the second generation submenu for the barebone examples of the Sons of Suckerfish vertical menus and the alteration that is required, which is used with all examples in this article.
#nav li ul ul {margin: -1em 0 0 10em;}#nav li li:hover ul {margin: -1em 0 0 10em;}The variations in bug fixes indicate that there no straight or logical pattern to treat the sticky hover bug, for what really is happening.
The barebones examples of the Sons of Suckerfish menus has a background colour for the ul element for the first submenu and the prettier version of Sons of Suckerfish menu has a background colour for the li element. Giving a colour to a selector or where you place the background colour can create a sticky hover bug fix or sticky hover bug. For the two examples, please follow this link for Sticky hover bug fixes with colour. The later of the examples shows that putting the same property on both the #nav li and #nav li:hover selectors can cause the sticky hover bug. The same applies if you have the same value, say width:6em on both the #nav li and #nav li:hover selectors.
Before we move on to the solution and enigma to the problem, I will explain another variant of the sticky hover bug or the same bug with javascript disabled, which I discovered at the beginning of writing this article. It was only happening with this webpage offline because it required the IE7 Information Bar to show which was blocking the javascript from running when javascript was disabled. It happened when the IE7 Information Bar reloaded after the page had rendered and caused the page to jump down quickly. The result was that the submenu of the menu item that I hovered would become sticky. None of the submenus of any other menu item that was hovered would show. Luckily this bug can be created another way, so here is a example of the Sticky hover bug variant.
The enigma behind the sticky hover bug in it various forms is how IE7 repositions a child element in relation to it parent element with a different offset value when the parent element is hovered. It remarkable is how IE7 behaves. In retrospect the CSS used in the Sons of Suckerfish menus is valid CSS, and with the IE7 now supporting dynamic pseudo classes all would be considered well, but what will be demonstrated in the next few examples is a bug that could apply to other situations when using dynamic pseudo classes with IE7, and indicating several things to avoid when using dynamic pseudo classes with IE7. For the examples, please follow this link for Sticky hover bug enigma.
The sticky hover bug and the bugs associated with hasLayout are part of a ocean full of bugs. Some sit alone and some mix with others causing all strange behavior. As this article involve, I look here and then I look there. I would say there is a new bug that has arrived with IE7 with how it supports the dynamic pseudo class hover on or when hovered off which I call the IE7 re-calculated offset with hover on or off bug and It is the bug that is behind and produces the Sticky Hover bug with javascript enabled or the Sticky Hover bug with javascript disabled or seen upfront when the hover is not honored.
This article was created on the 3rd of May, 2007 and last updated on the 24th of May, 2007