468,554 Members | 1,955 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,554 developers. It's quick & easy.

Adding delay to Suckerfish CSS menus

z
I'm using a horizontal CSS-based dropdown menu based on this code:
http://www.weblens.org/templates/sample_menu.html

Is there a relatively easy way to add a slight delay to the menu with
JavaScript, so that when you take the mouse off the sub-menus don't
disappear right away?
Nov 6 '06 #1
5 3717
z wrote:
I'm using a horizontal CSS-based dropdown menu based on this code:
http://www.weblens.org/templates/sample_menu.html

Is there a relatively easy way to add a slight delay to the menu with
JavaScript, so that when you take the mouse off the sub-menus don't
disappear right away?
That menu uses pure CSS for the menus for some browsers and a
combination of script and CSS for others (some will use both, results
may vary). The CSS is reliant on the hover attribute on LI elements -
it isn't supported by IE 6 but it is (supposed to be) supported by IE
7.

The script infers lack of LI hover support using:

if (document.all && document.getElementById) { ... }

which is clearly flawed logic - e.g. Opera supports li:hover and will
return true to the above test. Also, not all browsers that fail the
above test support li:hover, they will not see "drop down" menus (which
might be preferred).

As far as I know, you can't delay CSS effects like hover, but you'll
get a better answer in a CSS group:

news:comp.infosystems.www.authoring.stylesheets
<URL:
http://groups.google.com.au/group/co...esheets?lnk=li
>
--
Rob

Nov 7 '06 #2
RobG said the following on 11/6/2006 8:05 PM:
z wrote:
>I'm using a horizontal CSS-based dropdown menu based on this code:
http://www.weblens.org/templates/sample_menu.html

Is there a relatively easy way to add a slight delay to the menu with
JavaScript, so that when you take the mouse off the sub-menus don't
disappear right away?

That menu uses pure CSS for the menus for some browsers and a
combination of script and CSS for others (some will use both, results
may vary). The CSS is reliant on the hover attribute on LI elements -
it isn't supported by IE 6 but it is (supposed to be) supported by IE
7.
You can write it down as working in IE7 without the script in the page.
Saving it locally and removing all script blocks the menu works exactly
the same as it does in FF2.0 and Opera 9. It also made no difference
what DTD was present. Currently, the site has a loose DTD. Saving it and
changing it to a strict DTD had no impact on the menu. Maybe with IE7
going live more people will be getting away from IE6 and start using IE7
in the future.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 7 '06 #3
Randy Webb wrote:
Maybe with IE7
going live more people will be getting away from IE6 and start using IE7
in the future.
Anyone running Windows XP or later and using Windows Update will
essentially be forced to upgrade to IE 7. When that happens, it will
rapidly overtake IE 6 as the most common IE, and likely most common
browser, in use.

Maybe we'll see an explosion of IE version detection techniques and
forking code as a result - it can have its own private browser war all
on its lonesome. :-)

A benefit may be that users of Windows 2000 or earlier will move to
Firefox or Opera or whatever and realise that other browsers offer a
genuine choice.
--
Rob

Nov 7 '06 #4
RobG said the following on 11/6/2006 11:43 PM:
Randy Webb wrote:
>Maybe with IE7
going live more people will be getting away from IE6 and start using IE7
in the future.

Anyone running Windows XP or later and using Windows Update will
essentially be forced to upgrade to IE 7.
And being forced to upgrade from IE6 to IE7 is a bad thing?
When that happens, it will rapidly overtake IE 6 as the most common IE,
and likely most common browser, in use.
At least that is MS' hopes :)
Maybe we'll see an explosion of IE version detection techniques and
forking code as a result - it can have its own private browser war all
on its lonesome. :-)
That brings up a good question. How would you use object detection to
determine whether :hover is supported on li elements? Without resorting
to browser detection.
A benefit may be that users of Windows 2000 or earlier will move to
Firefox or Opera or whatever and realise that other browsers offer a
genuine choice.
Probably not though as people using earlier Windows either don't have a
choice (corporate decisions) or simply can't upgrade it to XP.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 7 '06 #5
In message <2f********************@telcove.net>, Tue, 7 Nov 2006
01:50:01, Randy Webb <Hi************@aol.comwrites
>RobG said the following on 11/6/2006 11:43 PM:
>Randy Webb wrote:
>>Maybe with IE7
going live more people will be getting away from IE6 and start using IE7
in the future.
Anyone running Windows XP or later and using Windows Update will
essentially be forced to upgrade to IE 7.

And being forced to upgrade from IE6 to IE7 is a bad thing?

With any forced change, there is a risk of breaking something on which
users are, rightly or wrongly, depending. For example, in Win98 I made
extensive use of an imported 32-bit utility which appears not to be
usable in WinXP (though the 16-bit version still works, many other
improvements and changes were made in the 32-bit one).

The intelligent plan would be for the upgrade to retain IE6 completely
unaltered but to install IE7 beside it (and likewise for all other
upgrades (apart from bug[*]/security fixes?)). The icons and menu
entries could call a small handler program which would enable either or
both versions to be started. OS changes might be needed to permit that.

[*] An unexpected bug fix might be worse in effect than the bug, while
in principle being correct. Consider a continuing set of disc data
"indexed" by week number from VBS DatePart("ww", <DATE>, vbMonday,
vbFirstFourDays) which seems wrong for 3 days per 28 years. Fixing
the bug would change the relationship between Gregorian Date and Week
Number in existing data sets.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Plaintext, quoting : see <URL:http://www.usenet.org.uk/ukpost.html>
Do not Mail News to me. Before a reply, quote with ">" or "" (SoRFC1036)
Nov 8 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Martial Spirit | last post: by
10 posts views Thread by Richard | last post: by
10 posts views Thread by Eric Petruzzelli | last post: by
23 posts views Thread by timmy | last post: by
3 posts views Thread by j0nharris | last post: by
1 post views Thread by =?iso-8859-1?q?Jean-S=E9bastien?= | last post: by
reply views Thread by Aljosa Mohorovic | last post: by
1 post views Thread by phpmagesh | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.