The only “drawback” of this method is that keyboard-users can’t skip links inside the current sub-menu.
If you prefer how the menu behaves in Internet Explorer without script support and want the same “look” in all browsers (except IE 5 Mac), then follow these two steps:
headsection to the
bodyelement and remove the Conditional Comment (first and last line).
<!--[if lt IE 7]> <noscript> <style type="text/css" media="screen"> @import "TJK_keyboardDropDownJSoff.css"; </style> </noscript> <![endif]-->
#TJK_dropDownMenu li:hover ul,
noscriptis not allowed in the
headelement. If it passes validation, it is because it is inside a Conditional Comment.
styleis not allowed in the
bodyelement so "downgrading" this menu to make it more accessible will invalidate the document.
I’m used to doing my testing with the oldest browser versions I have; my thinking is that if I can make it work in old versions, it should work in newer ones as well. Unfortunately, when working with CSS, there are no rules (pun intented).
It is Michael from Valley Web Designs who spotted a strange behavior in Safari 2.0.4., something that did not exist in version 1.3.
In version 2.0 - following a certain path - it was possible to keep sub-menus opened while moving from one to another [see test case]. If I say “it was possible”, it is because I found a workaround (reversing the stack order using “
It is not a perfect fix though, because it takes care of all sub-menus but the last one. If you use Safari v 2.0 you can experience the bug by hovering over the last sub-menu and going back up to the previous top level item (“articles: P-S”). An easy way to avoid this would be to style this last sub-menu as the others (no negative margin), but I think this is a minor issue and I believe this bug won’t come with future versions of Safari.