Ruthsarian Menus and Skidoo Redux Updates

Michael sent me an e-mail earlier this week with an interesting bug he’d found with the Skidoo Redux layout. Using IE7, if you drill down to the second level of a menu, click on an item that has a sub menu (we’re three menus deep at this point), but rather than complete the click, drag the cursor out of the menu entirely, then release the button, then go back into the menu, you’ll see the item you clicked and dragged from still in its :active state. Furthermore you’ll find a big white box covering the area where the third level menu should be.

That the item is left :active is simply how IE operates. IE doesn’t seem to remove an element’s active state until something else is clicked on (taking on its :active state).

But the white box is a bug. My guess is that it’s related to hasLayout. I’m guessing the third-level menu isn’t properly told to “undraw” itself and so some elements are left drawn on the screen. By applying min-width: 0 to the immediate child of an active LI element seems to force IE into correctly telling the menu to completely undraw itself when its parent is no longer in its :hover state.

rMenu.css has been updated with this workaround and anyone who is using Ruthsarian Menus should grab this file and replace their old copy with this new one.

While debugging this I also discovered Skidoo Redux was susceptible to the active scaling bug I wrote about a few months back. So I’ve updated the skidoo_redux.css file with the approperiate fixes and I cleaned up the CSS a little bit more as well as moved the overlap hack needed by older gecko-based browsers into its own section under HACKS in the CSS. If you’re using Skidoo Redux I suggest you grab the latest copy of skidoo_redux.css and apply it to your site.

Advertisements

2 thoughts on “Ruthsarian Menus and Skidoo Redux Updates

  1. Thank for the Hack update Eric.

    We appreciate your diligence.

    I’ve updated our modified version of Skidoo_Redux with them.

    Even after editing out your helpful comments it resulted in 22 lines of css hack code becoming 70 lines of css hack code!

    I’ve asked before, but is there anyway people on a virtual server can employ gzip to speed up loading of their sites?

    We failed on the YSlow site-speed test before we added the new css hacks, I daren’t test since :)

    PS. I hear ( from William Blum at killinghope.org ) that AOL are dumping their site hosting soon, so will their browser finally be consigned to the Museum of Tchno-Horrors?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s