When I tried to implement csshover.htc-enabled ADxMenu on the client website, I was greeted with very unpleasant behavior. On the very long page or complicated page, IE would freeze for a period of 10-15s. Download stops, but it does not give you the control over page until it finishes processing. Don’t know what exactly it’s doing, but I guess it might be going through complete document tree, for each new hover rule. Or I could be spitting nonsense.
Whatever it is, it was unbearable. Hence the version 2b.
I didn’t do anything spectacular. First, I reincarnated the double style rules – one for IE, one for all other:
#menu li:hover,
* html #menu li.iehover {
...
}
Then in the script, for each li element, I added the class changing code, shown here and there over the Net:
oMenuLI.onmouseover = function() {
this.className += " iehover";
};
oMenuLI.onmouseout = function() {
this.className =
this.className.replace(" iehover", "");
};
All else is identical to existing menus. For those who want to have perfectly valid CSS files, this script is the way to go.
I took the opportunity to implement WCH3. All 2.x examples are updated to use WCH3 and latest corresponding versions of ADxMenu script.





I’m afraid i have another question perhaps a little obvious. I I am now putting together my site structure and dividing the files into the respective folders. I spent a long time yesterday trying to figure out where to place the WCH, ADxMenu and csshover files so that it works. I went over and over it, checking the behaviour and import references in the files, but i was not able to get it to work properley. I think there must be a rule that I am overlooking or perhaps a link reference to these files that I have not seen. Please could you give me a clue again. This seems to be the only obstacle standing between me and my site redesign. Thankyou again in advance.
Links to both CSS and JS files should start from the calling document if you use relative paths. If you look at the source of any of my examples, you’ll see I’m using relative paths with lots of ../ in them. In CSS, you can use the same. Or you could use absolute paths and then you don’t have to worry about page position in the directory hierarchy.
For example, my usual directory setup is like this:
CSS files (and csshover.htc) goes to css dir, while WCH.js and ADxMenu.js goes to script dir.
So, in the menu.css (or whatever is called) I simply have
body: behavior:url("csshover.htc");which is relative path to menu.css.
Other option is to move .htc file over to script dir, when both of these would work:
body: behavior:url("../script/csshover.htc");— relative pathbody: behavior:url("/inc/script/csshover.htc");— absolute pathThis is good if you have several menu.css files in different directories, so you can use the same csshover.htc for all of them.
Also, in all HTML files, I have (absolute paths):
<script type="text/javascript" src="/inc/script/WCH.js"></script><script type="text/javascript" src="/inc/script/ADxMenu.js"></script><style type="text/css" media="screen"> @import url(/inc/css/menu.css); </style>I hope this helps.
The reason why examples use relative paths? I need them for downloadable archives (absolute paths does not work reliably without web server).
Hi
Only just found your menu. Wow! On the IE problem with behavior, have you tried putting it in the html tag instead of the body? IE treats the html style tag as the page root, not body.
On the IE5 problem. I know this sounds odd, but I was recently working on making an imageless CSS 3D menu system (single tier only), using nested divs and spans to make the ‘image’ of a button. IF I used UL/LI’s, IE 5 would NOT play ball. However, if I used DL/DD’s, IE 5 (Win and Mac) were both happy. Indeed, whilst not very pretty, even IE4 rendered something close. Just for fun, you can see the sample menu’s here (the css is inline, and it is valid xhtml1 strict):
http://207.44.137.103/stus_buttons.html
Trevor
Looks very good, Trevor. Went straight to bookmarks, for later disecting.
I did not try with HTML, as I was following the author’s guidelines. Will try, as I have a perfect test case in one recent project. :)
Hi Aleksandar
Just thought I’d let you know, that demo page has moved to here:
http://209.216.241.33/stus_buttons.html
Trevor
I’m trying to use this script for a dropdown menu, and I’m having that freezing problem. I’ve changed the script and removed the reference to the .htc file in the css. It doesn’t work now, which I expected, but now I can’t figure out what else to change. Can you clarify, please?
I think I’ve got it… I didn’t inlcude thie additional bit of inline javascript that’s in the example page. I also made sure to include the WCH file as well. Thanks for the great menus!
I’m messing around with the pure CSS basic example of your menu and noticed an issue. In IE, when you specify an alpha filter such as filter: alpha(opacity=80); –moz-opacity: 0.8; for the #menu li ul selector, the first menu to popup is translucent, but no more submenus popup. Something stops working as far as popping up the submenus. Everything works fine in Netscape.
Any thoughts?
Hi,
I’ve been using this nice menu of yours and came across a symptom with using it in IE. Dunno if this has any relation to those IE problems some of you have been having. If you do refreshes on the page and you also have task manager opened, you can see a memory leak in that browser process. The memory usage just keeps going up with each page refresh. It’s also having some strange effect on the mouse hover as I’ve an onclick event attached to the top menu element. I’ve traced it down to a local variable oMenuLI in the function _ProcessMenu. I’m not exactly sure why but it seems we have to set it to null before it exits _ProcessMenu for IE to release the memory resource. So much for IE’s javascript engine :)
Thanks for finding that memory leak fix. I have another feature I’m trying to get to work with this menu…
I’d like to be able to turn off individual list items (LIs) client side. Usually, you can just put an id on an LI then change it’s display property to none, but that doesn’t work in these menus. I can’t figure out what is preventing that from working. Any help making menu items invisible (and take up no space) clientside would be greatly appreciated. I’m also still trying to figure out why the opacity filter in IE stops more than first-level submenus from popping up.
Tim, quick answer on the opacity filter. I tried to use them to achieve shadow effect for the menus, I think in the 1.2 version, and bumped into the same problem.
Then I build a test case with two absolute divs, one nested in another. Parent had filter applied, and child was partially moved outside the parent area. As you can guess, outer part of the child div was not shown.
I believe that this is the way IE internally works — in order to apply the filter, it effectively cuts everything outside the block where filter is applied, including any content in it.
And to all: thanks for your time and posts. I do read them, but I still fail to complete the next version. Hopefully, when all is done, menu will be more versatile, although I somehow doubt I will be able to cover all the bloody problems I encountered.
I seem to be having the same problem that Richard has.
I read your instructions carefully, reviewed all the links (either relative or absolute, as in the solution you presented to richard), even recreated the structure /inc/scripts; and /inc/css; but the only way it seems to work properly in IE, is if i put a copy of menu.css in every subfolder that has a .htm file linkin to it, eitherwise, the conection between menu.css and .htc file seems to dissapear.
Any pointers?
Thanks
None Paulo, other than to post the whole thing online, so I can take a look.
I am having the same problem as Paulo and Richard. If I use absolute paths the htc is included and everything works fine. But if I use relative paths it never finds the htc file. I use this in my main css, the htc file is in the same directory as the css file.
behavior: url(“csshover.htc”);
I took a look at the server logs and it asks for csshover.htc in the root without taking into account the location of the css file that includes it.
Any ideas?
GOT it!
I found a link to someone suggesting that Microsoft behaviors are not relative to the including CSS sheet but are relative to the document that they are included in. Since I use a JSP server where all of my documents appear to be served out of the root I went ahead and tried it. It works, since it appears to the browser that all of my documents are in the root placing it relative to them makes the request for the csshover.htc succeed.
The link to the info is:
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-June/000016.html
Hope this helps someone else, a long search for an answer that is less than ideal but certainly adequate for my current needs. If anybody finds a better solution let me know.