These bugs are introduced in the beta2, as the menu was working fine with beta1. New IE engine’s growing hickups, I guess.

Update: Microsoft developers fixed this in IE8. My menu is working just fine there.

I have recoded this so that my script is now completely independent of anything else on the page. Everything is up, so you can re-download the script and use it.

p.s. This is 300th post on my blog. I find it nice that it’s ADxMenu themed.

I was wondering how one might be able to modify your ADxMenu so that if someone has IE6 and Javascript disabled it would simply show the entire tree menu.

I prefer to add actual links to main menu items and have sub navigation shown on each of those pages. However, this is reasonable request that improves the accessibility of the menu, thus I looked into possible solution. I wanted to avoid changing HTML for the menu and I think I came up with good solution — keeping in mind that this will be seen and executed only by IE6.

The main four menu examples are updated, as well as downloadable archive. There’s also one new example that shows how you can create two different styles, one when Javascript is enabled and one when it’s disabled.

How it works

Part of the CSS that initially hides submenus is this:

.menu ul {


	visibility: hidden;


	position: absolute;


} 

Thus, for IE6, that had to be removed and activated only if Javascript works. Which means that now, inside the conditional comments I have this:

.menu ul {


	visibility: visible;


	position: static;


} 

and the new version of the ADxMenu.js contains this bit (it’s all one line, broken here to be more understandable):

document.write('<style type="text/css" media="all">' +


'.menu ul {visibility:hidden; position:absolute;}' +


'</style>'); 

I avoid document.write in my code as much as possible — the correct place to do this would be in the Setup method, for each menu found on the page. However, that means that menu will be visible even with Javascript ON, for that brief moment or two until script kicks in. Since this is custom made only for IE6, shown code line is better solution.

A step further: different styles

I have a hard time visualizing menu that would look acceptable with Javascript on/off and to use the same styles. Even with simple and short menus, I don’t think it would look fine in most cases.

Given that, the script now has this line:

aTmp[i].className = aTmp[i].className.replace("adxie", ""); 

where aTmp is an array of menu elements that have the adxm class. This requires you to add one more class to the main list, like this:

<ul class="adxm menu adxie"> 

Using this class, you can then create IE6-only styles for the case when Javascript is OFF and leave the usual menu styles for the case when Javascript is ON. For this to work, make sure you write the JS-ON styles first, then the JS-OFF below them. The new example shows just that.

If changing the menu HTML is not an option — like too many existing pages to be updated in reasonable time — then you can do the reverse thing. Comment-out the previous line in the script and uncomment this one:

aTmp[i].className += " adxie"; 

Thus, you can use your existing menu class to style the JS-OFF solution and adxie to style the drop-down case (JS-ON). First solution is noticeably easier to do and maintain, so go with it if possible.

I took this opportunity to rewrite the script a bit, nothing really important. There you go, 1st update of the menu since January last year. :)

With several simple lines in the script, I can now use much simpler IE6-only CSS. Menus now work with any number of levels, without the need to update the ugly .menu .adxmhover ul, .menu .adxmhover .adxmhover ul, .menu .adxmhover .adxmhover .adxmhover ul.... rules.
Even better, you now have — in IE6 — direct (not simulated) replacements for the following selectors:

• li:hover
• li:hover>a
• li:hover>ul

Script changes

It’s so simple.
I’m using script for IE6, in which I’m already using this replication of li:hover:

oLI.onmouseenter = function() {


	this.className += " adxmhover";


...


}; 

which is then used in IE6-only styles as li.adxmhover. Well, why not add more replacements? With this:

oLI.UL = oLI.getElementsByTagName("ul")[0];


oLI.A = oLI.getElementsByTagName("a")[0];


oLI.onmouseenter = function() {


...


	this.UL.className += " adxmhoverUL";


	this.A.className += " adxmhoverA";


}; 

I can replace li:hover>a with a.adxmhoverA and li:hover>ul with ul.adxmhoverUL.

No need to simulate anything, simply repeat the style rules in IE6-only part using replacement class selectors and…that’s it. You can of course update the script and add replacements for other advanced selectors, but this is basically all that I ever needed in menu styling.

CSS changes

The whole thing started with IE7 problems with display property. I recoded CSS to use visibility instead, but then Safari went scrollbars-crazy — it was due to this:

li { position:static; }


li:hover { position:relative; } 

I then tried this:

li { position:relative; z-index: 5; }


li:hover { z-index: 10000; } 

but IE7 ignored z-index change. Now really on the end of my nerves, I coded horrible positioning trickery (horizontal bottom-top variant was the worst) to minimize all problems. Luckily, good man David pin-pointed solution for IE7’s li:hover issue.

At this point, I was so happy :) that it’s no wonder ideas sparked all over the place and dust was off the mind corner where replacement class selectors peacefully nap.

Wrap up

Instructions page is updated, Troubleshooting is a lot shorter and 4 basic examples are updated to latest code.

I have changed the basic CSS, but just a bit, mainly simplified it. Important changes from the v3 are:

1. Completely clean HTML inside the menu — there are no classes, no IDs
2. Behavior component (.htc) is not used anymore — it uses plain Javascript
3. Instant execution of the IE script, thus making the menu usable even before the entire page content is downloaded
4. WCH is not part of the script, but it uses it if it’s available You must include WCH.js before the ADxMenu.js for this to work
5. li:hover is not simulated automatically, you must write the CSS yourself, using adxmhover class
6. Submenu opening now gives you certain degree of freedom — they will not disappear if you move the mouse slightly off the submenu
7. Much, much quicker in IE than v3

The most important improvement is certainly the last one. I wrote 1.5 years ago about the speed issues of the ADxMenu v3. The good thing about the .htc-based version is great CSS ease of use; bad thing: only usable for small menus. I posted a quick JS-based fix back then, but it was applicable only in controlled cases. For longer menus it was simply not good enough, and usability is what counts in the end. This version is speed beast.

This new version is simplification effort. I have gave up on the “ultimate”, “enterprise” and similar adjectives. From the implementation questions I receive on the daily basis, I realized that it’s not really possible to make it work in like 1–2-3, for all people and for all cases. Thus, the clean-up.

The cleanest HTML you can imagine

The basic CSS and the script require no IDs and no classes inside the menu body. The only thing required is that you put class="adxm" on the main ul element and that’s it. In browsers supporting li:hover and li>ul selectors, that is all that’s needed.
Obviously, if you have more than one menu on the page, then you would use something like: class="menutop adxm" and class="sidemenu adxm".

Any other classes and IDs you add can be used to implement complicated designs, icons or whatever.

Javascript for IE6

If you look at the source code of the examples, you will see how easy is to add it:

<!--[if lte IE 6]>


<script type="text/javascript" src="ADxMenu.js"></script>


<![endif]--> 

What does it do? It looks for all ul elements with the class of adxm. Then for each of them fetches all li elements and looks for those that have nested lists. It attaches the following two event handlers on matched li elements:

// li:hover


oLI.onmouseenter = function() {


	this.style.position = "relative";


	this.className += " adxmhover";


};


//	li:blur


oLI.onmouseleave = function() {


	this.style.position = "static";


	this.className = this.className.replace(/adxmhover/,"");


}; 

The newly created class can then be used to replicate the :hover and the child selector, in the following manner:

.adxmhover ul,


.adxmhover .adxmhover ul {


	visibility: visible;


}


 


.adxmhover li ul,


.adxmhover .adxmhover li ul {


	visibility: hidden;


} 

Easy peasy.

Why the position setting? It’s a well known fact that IE6 has faulty implementation of positioning context stacking. That leads to huge problems, one of which is illustrated in the short example I mocked up, where that line is deleted from the script. Using this line, only the currently hovered item has the position set to relative and thus there are no problems with context stacking.

Speed daemon

Consequence of this positioning trickery is that IE is constantly re-rendering the page, since position:relative changes the position of the nested submenu. This is the major source of the speed issues in IE, when mouse is quickly moved up/down on the large menu. Take a look at the example using old .htc-based code, in IE (you can witness the freeze at the start of the page while .htc works). Hover any item in left-hand menu, for instance soccer or horse racing. Then move the mouse up and down — IE will visibly lag behind your movement. When looked in Firefox, all is breeze, as they implement context stacking properly and do not require this position trickery.

And now look at the same page design, same menus, but using v4. Repeating the test from above, you can see that everything is breeze in IE too.

Usability

The advantage no.3 from the list at the post start. Huge usability improvement, especially on large, heavy pages. Having the script executing practically immediately after .html page downloads, without the wait on flash files, videos, images — this is my second favourite feature of the new version. I have prepared the example that demonstrates this — menu is working in IE before the image has finished downloading. You people with those damn fast internet links might not even notice this, if the image downloads in few secs. We, ones with cheaper tickets, have no such “problem”.

All thanks goes to Dean Edwards, Matthias Miller and John Resig, plus Rob Cherny for a lovely script I use.

Onmouseenter, onmouseleave

These two event handlers are IE-specific. Very useful little devils. I have used them on the latest variants of the v3, but I mention them here mainly to illustrate how much better they are, for this case, then onmouseover and onmouseout. The example (open it in IE) open small window in the top right corner and populates it each time any of these 4 handlers are called. Move your mouse around the menu and be ready to puke at the number of times onmouseover/out are called.

This nicely influence the speed, in all the good ways.

A degree of freedom

Credits for this goes to John Gallant of the PiE fame. In his flyout menu example, he implemented a fabulous little trick, shown on the following screenshot.

He placed each of the nested lists inside a div, which was slightly larger than the list itself, by adding padding to it. The whole div is then negatively margined for the same value used for padding. Since div is transparent, you don’t see this, but you notice that submenus does not disappear when your hand slips a bit off the submenu. Not 100% slip-proof, but very close.

My examples are so simple, that I don’t even need the extra element and use the nested ul elements for that, while all the styles are applied on the li elements.

Your turn

There you go. Checkout my simple examples, fly through the instructions and don’t forget to check the Troubleshooting section if you have problems.

And implement, implement, implement…

I just tried latest IE7 beta 2 (so called MIX06 release) and examples work as expected (did not fully tested though, just the basics).

# CSS 2.1 Selector support (child, adjacent, attribute, first-child etc.)

Thus, from IE7 beta 2 (maybe) and IE 7 final (for sure) ADxMenu will work without helper scripts (at least in the standard version). The long walk towards IE6 1% records will then begin.

However, performance issues are not defeated yet. In the last project I’m working on, I have three menus on one page and two of them are very large. The page itself also features a great deal of various positioning, using both floats and pos/abs position. Accompanied with these three menus, this brings IE to its knees — it takes him 4-5s on P4-2.8GHz with half-gig of RAM to render that page and execute the .htc. 90% of that freeze time goes on .htc processing.
But not only that. Since my css applies position:relative on li:hover and thus does the actual positioning in that moment, re-rendering of the page takes some time and going from one menu option to another has a very noticeable lag. Last time I have seen such behavior was with Netscape Navigator 4. Sigh…

I created test page with completely stripped-down page leaving just menus where you can still notice the lag, both on page load and when traversing the left-hand menus — for a fraction of second you can see the busy cursor popping up. The numeric value in the middle is how long it takes IE to complete the .htc processing. And than imagine how this looks like when Sports menu has 3x more items (as is the case on production environment).

I spent entire afternoon, measuring where is all this time spent. It appears that each currentStyle.addRule call takes about 50-60ms, and some 1s is lost on function calls overhead. I don’t see a solution with .htc anymore as it seems that IE’s Trident engine has its limits. Pages that use heavy positioning are simply not what IE can handle well. I could be wrong, but the more positioning I add, the less responsive it becomes.

It is time for different IE strategy. I could easily end up dumping .htc all together and go back to Javascript and delayed initialization. This could prove to be a good thing after all.

For those interested, I resolved the perfomance problem by completly removing .htc, rewriting the design rules so that none of them used li:hover and execute this script on window.onload:

xGetElementsByClassName("adxm", document, "ul", function(oUL) {


	xGetElementsByClassName("submenu", oUL, "li", function(oLI) {


 


		oLI.onmouseover = function() {


			if (!this.UL)


				this.UL = oLI.getElementsByTagName("ul")[0];


			this.UL.style.visibility = "visible";


		}


 


		oLI.onmouseout = function() {


			this.UL.style.visibility = "hidden";


		}


 


	} );


} ); 

And this works near instant.

During development, I accidentally found the problem in IE, with .htc. If you have some :hover rule which is empty, IE will throw “invalid pointer” error. I updated all .htc files to fix this — they are all now in .21 version.