ADxMenu on A+ programming moments

IE8 beta2 considered harmful

Sun, 18 Jan 2009 13:53:17 +0000

I was notified that ADxMenu does not work in IE8 beta2. Apparently, it suffers from several CSS bugs that are triggered by my menu. Nothing to actually do about it, only hope that Microsoft developers will fix these soon.

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.

Small update for ADxMenu

Wed, 28 May 2008 10:51:48 +0000

I implemented the latest version of the ADxMenu script in company’s web sites and found a problem. I use the full version of DOMLoaded.js script for those websites and ADxMenu.js internally uses just the IE part of the same script.

When loaded both, they collide and ADxMenu’s Setup() is never called.

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.

ADxMenu accessibility update for IE6

Thu, 17 Apr 2008 22:58:03 +0000

Aaron J. Young from OUHSC recently wrote with question:

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. :)

ADxMenu v4.10

Fri, 05 Jan 2007 22:31:58 +0000

After finishing this update, I had yet another moment of how in the hell I didn’t figured this before. You know the feeling - you struggle with certain code for weeks or months, and then after you surrender to the reality and code the “just work, bitch” parts, you realize the simple solution was waiting just around the corner of your mind.

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.

ADxMenu v4 - flyout (drop-down) menu

Tue, 12 Dec 2006 00:01:00 +0000

v4 is online for some time now and people have already used it. This version is the result of the months and months of experience implementing previous version on all kinds of web sites.

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

Completely clean HTML inside the menu - there are no classes, no IDs
Behavior component (.htc) is not used anymore - it uses plain Javascript
Instant execution of the IE script, thus making the menu usable even before the entire page content is downloaded
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
li:hover is not simulated automatically, you must write the CSS yourself, using adxmhover class
Submenu opening now gives you certain degree of freedom - they will not disappear if you move the mouse slightly off the submenu
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:

[code]

[/code]

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…

IE7 is ADxMenu compatible

Tue, 21 Mar 2006 17:47:54 +0000

It really is.

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

Ooooh, yes!

Sat, 30 Jul 2005 23:37:12 +0000

# 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.

End of the road?

Sat, 07 May 2005 12:14:12 +0000

My long-time readers may remember that, back in the early days, ADxMenu had two versions. One that used .htc file and only one set of styles and the other that used only javascript but two sets of styles. The reason was that .htc version at that time used original Peter Nederlof’s csshover.htc which went through entire document looking for elements to apply :hover trickery and thus had far from good performance on very long pages.

Things changed when I recoded it to work only with menu elements and ADxMenu 3 utilized it to its fullest potential.

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.

Small update

Mon, 21 Feb 2005 21:58:29 +0000

I have updated the example listing with an example of menu with horizontal submenus. This was asked several times and I got time to do it last week while staying at home, recovering from the flu (or some similar thing).

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.

Porsche.GB with new (web) engine

Mon, 29 Nov 2004 17:45:24 +0000

I was surfing the web on Friday looking for examples of good drop menus I could replicate using ADxMenu, to fill-up the examples sections. I was fairly positive I could find lots of such on automotive sites, as for some reason they tend to have them in packs.

After few attempts, I found a web site that immediately presented itself as perfect example for the use of ADxMenu, and also for CSS-based design.

I present you recoded Porsche GB, using no tables and full power of ADxMenu.

Analysis

I started from the snapshot I took in Firefox on Friday, Nov 26th. One look at the web code and you can clearly see the trade-marks of last century designs:

dozens of trans.gif (usually called spacer.gif) images
extensive use of inline scripts and styles (even with several external files)
lots of nested tables

The actual snapshot I took also had display:none hard coded on the large banner in the middle and on the second banner (composite brakes) below it. This has lead to design fall-out, as images for the upper row of navigation were misplaced, and the popup menus for the lower nav row completely covered the images (can still be seen on the live site, at the moment of posting this entry).

The page foot-print is 54kB, with additional 62kB of scripts, spread over 7 files.

Re-coding

Removal of unnecessary markup and creation of large navigation lists took me roughly 1.5h - I hate copy & paste. Coding appropriate markup for the design took less than an hour (I went for XHTML 1.0 Strict). Which left me with CSS and imagery.

On/off states for navigation images are merged into one image and with CSS development and clean-up it lasted about 3-4h.

End result was tested in a variety of modern browsers. Firefox, IE6 and Opera 7.52 display as I intended it (with small but acceptable hick-up in Opera). Safari, Omniweb and other WebCore co. have no support for min-height (which I used for navigation lists). Thus I was forced to compromise on bottom navigation. Instead of having 75-80px for bottom position of the submenu, I used 50px so you can actually move the mouse over to submenu. In Opera 6 it looks just as in Safari (sans the submenus, of course), and almost perfect in IE5/Mac - if you know why is that content block moved to the left, please tell.

All in all, it was a nice exercise for a lovely grid design, and a wonderful example of menu use.

The page is now 8.4kB, which means that savings are over 80%. It also has several .css files which would be merged into two files if I were doing this for production site + .htc file for IE - all combined it makes 13kB, giving another 80% saving on external files. Since I have merged navigation images I have very important savings on HTTP requests - about 2x down from the original number.

Benefits are more than obvious.

Last thoughts

For this design, I think that images in the navigation are an overkill. The page is graphic heavy as it is, and I think that it looks better with just words. Original site uses animated GIFs for the text - I used text for better usability, with few compromises to account different text size. I also fixed the size of the header area to match the width of the grid.

The grid size is 783px which is 13px above what I consider the safe limit. Hence, in 800x600, horizontal scrollbar appear, so this should be fixed as well.

If you remove some of the banners in my recoded page, nothing will break - elements will simply reflow. In current design, this is not the case.

Both ADxMenu and modern web design technologies simply shine in this real-world example. Porsche is not the only design with lots of menus and I can only hope that 2005 will be the year when nested tables and unnecessary use of Javascript will start to disapper significantly.

The ultimate drop menu

Fri, 26 Nov 2004 16:10:16 +0000

ADxMenu - multilevel menu built from nested HTML lists - is my pride and joy. I began working on it last year, always implementing the good stuff I learned on the web standards road. In its current incarnation, I believe it’s best of the breed. There are other menus out there (using the very similar HTML base), but most of them can, at most, measure up to ADxMenu standard.

With that said, I want to repeat what was my target from day 1. It’s valid, standard-compliant web sites. If you have an old-school web site with nested tables and no DOCTYPE - do not bother; you have other things to conquer first. On the other hand, if you are a CSS newbie/inter/pro - you are welcomed. You will need good CSS skills to create attractive menus though; I did my best to give you a good starting point, for 4 different variants of the menu, but the final look is up to you.

There are many old-school menus with large scripts and over-bloated markup. Those few that are good and light are not free. ADxMenu3 is free to use on any kind of site, as long as you give proper attribution.

Versions

ADxMenu3 comes in three flavors.

Standard version is for sites with no forms (at least no select boxes in forms), and for small menus. Long menus tend to fall out of the visible part of the screen, which is not very user friendly.

Professional version builds on the standard, adding WCH implementation. That means that your menus will be placed above any form element on the page, including the select boxes in IE (the usual problem). Again, make sure your menus fit in the reasonable desktop size.

Enterprise is intended for sites with long submenus. For sites where you must be sure that menu stays visible. It includes additional scripting which checks for menu position and moves it in the opposite direction if it’s off-screen. It’s clearly the best choice for commercial sites, unless you are sure that your menus will always fit in the visible part. If you are, then you are better off with one of two lighter versions, as you will have smaller download foot-print.

Switching between versions is easy, as CSS and HTML markup are same for all of them. What changes is the accompanying scripts and the code you use to include the files. Instructions for all of this can be found on the Intro page.

Accessibility issues

These menus are always branded as utterly non-accessible. True, they depend on the precise movement of your mouse, thus making it inaccessible for people with disabilities, as they will have a hard time fetching items in the second or third nested submenu.

However, this is not the problem with the menu itself. It’s with the site IA designer.

Online shop is the typical example. You start with merchandise types (books, games, music etc.). Then when you click on “books” you could have Latest, Most popular, A-Z, Recommended, etc. You need to build such site to be usable with simple links - no menus or search. Only then you can think about drop menus.

So, each item that has submenu must itself be linked to a page that contains “normal” list of items from that submenu. By doing this, you solve not only mentioned accessibility issues but are also supporting older browsers. The way CSS is included (@import) prevents very old browsers like Navigator 4 or IE4 to even see the styled menu.

On the other hand, browsers like IE5/Mac or Opera 6 have decent CSS1 support, thus being able to see and load menu .css files. Due to use of CSS2 advanced selectors, they will never show the submenus, thus creating usability problems if you do not link the main items to appropriate pages.

Always think deep about your site IA. Using ADxMenu as the only source of site nav will only get you in trouble. Use it to speed navigation up. That is its purpose. That is where it shines.

New ADxMenu in sight

Fri, 19 Nov 2004 15:07:23 +0000

You might’ve not noticed, but beta version of ADxMenu 3 is up since the new blog was published. There are still loose ends in the enterprise version, but the hardest part is over and I can proudly say that it promises to be the menu, for all sites and possible uses.

Highlights:

submenus can freely go one over another, even in IE (no unwanted overlap anymore)
clean separation of IE hacks in separate .css file, which only IE loads
reworked whatever:hover so it deals only with menu elements (no page-onload freeze anymore)
three different version, so you can pick what suits you best
mildly simpler CSS

I’ll be away this weekend, but you can expect full write-up next week. Until then, please report errors you find (and in which browser, version) in comments.

There's some light at the far end...

Tue, 28 Sep 2004 15:41:29 +0000

Four variants of drop-down menu

Thu, 08 Jul 2004 13:26:27 +0000

It seems like years…

Having established (or so I thought) the basis for good, versatile, menu system, I figured it’s about time to make it truly powerful. I wanted it to:

be placed anywhere and to open-up in any direction
work in CSS2-capable browsers and IE5+/Win
provide b-version script for use with other browsers (mostly IE5/Mac)
circumvent the drop-down problem on IE/Win
avoid scroll bars upon page load (while menus are hidden)
prevent IE from drawing tall submenus over prev/next parent menu options

Well, I did all that, and I did none of that.

Basis

For those of you late-arrivals to the party, this menu uses nested link list as its HTML, and then uses a bit of CSS to provide the drop-down menu.

Then, on top of that, it uses a bit of Javascript for the following tasks:

prevent HTML select boxes to go over submenu, in IE/Win (using my WCH script)
keep the menu inside the visible portion of the window area (reposition)

First task was thought to be easy. WCH script, in its 3rd version, is stable, heavily tested and used on a variety of web sites I built. Well, while implementing some of the requirements for this version, IE caught me with my pants down. Read on to see how.

Second task dragged me into the hell of incomplete CSS-P/DOM implementations and an amazing array of browser bugs. The most amazing part was that browser with least problems (if any) was IE/Win. All those nice, modern, standard-compliant browsers were tripping me every inch of the way. Read on to see how.

In some cases, even the mere task of drawing the main menu was not possible (now, this was IE).

Version 2.5

I thought that this would be version 3, but due to unfulfilled goals, it had to be downgraded.

The HTML structure remains the same: nested ULs, with As in each LI. For IE/Win, csshover.htc is used to simulate li:hover.

CSS has changed a bit, but not that much. I’ll repeat the basic instructions, and leave you to dissect the examples and build your own designs.

Main example for this version is using WinXP look, and I provided the following variants:

HBT: horizontal main menu, submenus drop-down (top to bottom)
HTB: horizontal main menu, submenus drop-up (bottom to top)
VLR: vertical main menu, submenus drop-right (left to right)
VRL: vertical main menu, submenus drop-left (right to left)

This is the only menu style featuring all variants, both pure-CSS and scripted. I picked this one because it’s the most complicated style I could think of. Its items (LI) have margins, paddings, borders and icons - all possible causes for various (re)positioning problems. If this is ever made to work properly, then any other style would work by itself.

All other examples have only HTB variant; the task of keeping all of them up-to-date is taking way more time then I’m able to put aside for this.

HTML code

HTML is very simple so I won’t go into details. I only want to emphasize one important bit I kept forgetting in previous write ups. Wrapping div and each ul must have an id attribute. It is essential for WCH script to function properly. Also, you must place class="submenu" on each a element followed by nested list.

CSS core

This is brief walk-through of the CSS build-up for all menu variants. In actual menu’ .css files, this part is denoted as Basic style.

Horizontal main menus are made of floated list items, so if you want to have a background/border on it, you need to provide the appropriate height value. Since this is highly dependent on design (done in Make-up part of the .css), you should do it there.

For vertical menus, same counts for width, or your menu would take up all available width.



#menu {

	/*

	height: ??;		Hxx

	width: ??;		Vxx

	*/

	display: block;

}

Then remove all list-specific attributes. List items are blocked, floated and relatively positioned, so that submenus can happily open next to their parent item. float:left part is not needed for vertical menus, but that can depend on your design and HTML code.



#menu ul {

	margin: 0;

	padding: 0;

	border: 0;

	list-style-type: none;

}



#menu li {

	margin: 0;

	padding: 0;

	border: 0;

	display: block;

	float: left;

	position: relative;

}

Then turn links into blocks, to have more fun when styling. The second rule is for IE, mainly IE6 and it is there to fix its inability to expand clickable area. Although it visually do that by itself, link-click functionality exists only on actual text of the link. It seems that changing position fixes this - great find by Douglas Clayton.



#menu a {

	display: block;

}



* html #menu li a {

	position: relative;

}

All submenus are hidden initially. Best way to do this is to completely remove them, using display:none, so there are no unnecessary scroll bars. It works as it should, for all but IE due to a whole array of problems, explained further below.



#menu li ul {

	visibility: hidden;

	position: absolute;

	z-index: 10;

}



html>body #menu li ul {

	display: none;

}

Each submenu list item should be 100% wide, so that menus look like menus. Again, thanks to wonderfully non-practical W3C box model, this is possible only if you don’t have paddings on LIs. If you do (like I have in WinXP style), then you need to tweak this in the make-up part.



#menu li li {

	width: 100%;

}

Now comes the part responsible for menu acting as menu. First, set the position of the submenu, in respect to its parent item and in respect to direction in which you want it to open up.

For horizontal menus, 1st submenu will open as needed, by default. The rest of them needs a tweak. For HTB variant, it should open on the right of the parent item, so it goes like this:



#menu li li ul {

	top: 0;

	left: 100%;

}

For HBT (drop-up), bottom edge of the 1st submenu needs to be moved up a bit. The value of bottom highly depends on the make-up style, so be ready to tweak it as needed.



#menu li ul {

	bottom: 1.5em;

	left: 0;

}

#menu li li ul {

	bottom: 0;

	left: 100%;

}

VLR variant is the same as HTB, expect the selector is one way down - it applies to the 1st submenu as well.

This also illustrates the solution for the problem that sometimes appears, when on initial page load huge (more or less) horizontal scroll bar appears. This way, at initial page load, all menus are in top-left corner (of the page or of the parent list item). This can be applied to all variants, not just VLR.



#menu li ul {

	top: 0;

	left: 0;

}

#menu li:hover ul {

	top: 0;

	left: 100%;

}

Finally, for VRL variant:



#menu li ul {

	top: 0;

	left: 0;

}

#menu li:hover ul {

	top: 0;

	left: -100%;

}

Last bit is show/hide. Since IE does not support child selector, we need to simulate it. Add as many levels of this, as needed. Number of lines (or number of li:hovers) should equal the nesting level.



div#menu li:hover ul,

#menu li:hover li:hover ul,

#menu li:hover li:hover li:hover ul {

	visibility: visible;

}

div#menu li:hover li ul,

#menu li:hover li:hover li ul,

#menu li:hover li:hover li:hover li ul {

	visibility: hidden;

}

The following rule is for browsers supporting CSS2 selectors, with increased specificity (to override the previous simulation for IE).



#menu ul#menuList li:hover>ul {

	display: block;

	visibility: visible;

}

Examples

As usual, examples can be found here, also linked from the side column. As said previously, WinXP style offers both pure CSS and scripted version. First ones should be used on simple pages and with simple menus. If your page has select boxes or you have long menus, then you are better off with scripted version. Scripteds are an upgrade of the pure CSS variant - you just add links to two scripts and the following line of Javascript:



ADXM.Add( "menuList", "H" );

First parameter is the id of the main UL (not the wrapping DIV). Second parameter is either “H” or “V”, specifying the type of menu. It is optional - if this is anything other then “V”, it will be treated as “H”.

Also, for CSS validity reasons, note that csshover.htc is removed from the .css and placed inside of IE’s own conditional comments:

<!--[if lte IE 6]>

<style type="text/css">

body { behavior:url("csshover.htc"); }

</style>

<![endif]-->

This is an example - you make sure that path from HTML document to .htc is correct.

There is also an example of b-version of the script. Here, the script takes the role that csshover.htc had - this can be used on long pages (where .htc freezes the page) and if you need to support IE5/Mac (or any other browser without li:hover support).

Weirdness, anger, despair…

For the longest time, I thought is it really worth it to publish this. What won me over is the fact that best menus are simple menus, where most of problems would not show and when menus actually work quite nice.

For the sake of information and for the hope that some of you might solve one or few of the problems, here it comes. First the problems appearing in the pure CSS, and then those in the scripted version.

Opera 7.5x weirdness (pure)

When 3rd level submenu is opened in Opera, you get the display as shown. I tried this with latest Opera (7.52). It happens with all variants, in pure and scripted version. You don’t even need to move the mouse over that submenu - hover its parent item (Hardware) then move the mouse down to Electronics - the submenu will stay visible in its messed form.

If some of you don’t find a solution, I will post this as a bug to Opera Software.

Box model problems in IE5.0

Due to different (better if you ask me) box model, IE5.0 has slightly different display. Shorter item is due to padding-left:29px. I did not want to fix this, as it is not creating functionality problems.

Also note the taller main items, because of white space bug. To fix this, you need to either float the items or connect list items on one line (in .html).

This is probably happening in 5.5 two, but I had no chance to even take a look at it, because…

Vertical weirdness in IE 5.5

…of this fine behavior in it.

No comment.

HBT impossible in IE5.0

This is the problem I covered before. If you replace visibility with display, then it sort of gets itself in order. But IE has other problems with display…

Safari bug 1

Horizontal menus in Safari have no background on hover, because the main menu items are floated. If you remove the float (or take a look at vertical variants) then all is well. My Safari is 1.2.2 (v125.8).

Background color does appear when Safari is forced to withdraw the screen; if you open Hardware submenu, scroll bar usually appears and then highlighted state shows up.

Safari bug 2

In the first tests, when I was playing with the following combination:

#menu li { position: static; }

#menu li:hover { position: relative; }

…I got another problem with Safari. It will show the submenu properly, but fail to remove them from the screen on mouse-out.

Overlapping in IE

The best part from the previous version is now lost. The CSS bit from above (in Safari bug 2), had one fabulous benefit in IE: it prevented idiotic overlapping of the menus. But the fact that items were static caused their submenus to be initially placed outside of the screen, thus introducing hor. scrolls.

Horror is totally unleashed in scripted version.

Why did I change this back to lousy variant? Because of Safari bug? No. Read on.

overflow:auto (scripted)

If you have a rather long menu, and an unusually small screen, then you might end up in the situation where your submenu is taller then available viewport (same applies for very wide menus). Natural thing to try here is to set the submenu’s overflow property to auto, enlarge the width (height) of it for some safe value to cover the width of the scroll bars and then let the user scroll.

Not possible my brother - as soon as overflow is applied, all browsers fire mouseout event and your menus disappear.

Firefox and Opera, HBT (scripted)

Firefox and Opera 7.5 were the only browsers (outside of IE) where repositioning worked as it should. Except this problem with drop-up menu (screen shows the state after repositioning). The visible part finishes at the exact point where bottom edge of the submenu was, before it was moved down.

Since both browsers behave identically, this might be my error, although I can’t seem to find it.

NN7.1 and Safari (scripted)

Both of these had to be excluded from the script, because of incomplete DOM implementation. Safari has even worse problems, ones I can only describe as erratic. It still has a long way to go. Don’t know about you Dave, but to me this seems more important than proprietary HTML extensions.

IE mayhem

Welcome.

Remember this entry? IE = P(iece) o(f) C(rap)? Here is the drop(s) that pushed me over the top.

Before all, comes the simulation of li:hover with csshover.htc and simulation of li>ul, as explained in the CSS walk-through above. That .htc is basically Javascript, run on page load. As such, it takes some time to be executed, so it can’t be used on very long pages.

What it does is that it adds onmouseover and onmouseout event handlers for LI in the menu and also dynamically creates special classes that are identical to li:hover rules in the CSS. First handler changes the class of the LI to corresponding class. That also takes time. It might be milliseconds, but it still takes time. Remember that.

Now one part of the answer why I gave up the solution for overlapping.

Changing the position property for the element is also done in runtime, in about the same moment as previous class switch is done, right after that actually, if I’m not mistaken. Remember this as well.

Now, the second part of the answer.

My ADxMenu.js script, adds another onmouseover/onmouseout pair of handlers. For IE, those handlers call WCH.js (to hide select boxes), as well as repositioning function. Both WCH and repos needs to know what coordinates they will use when calculating the menu position. Third remember.

Well, if you combine those three bits I told you to remember, you will get highly unstable situation, where God knows in what order they will be executed. They need to be done in the exact order I lay them out here, or the repos will not work and WCH’s iframe will be created in the wrong place.

Completely uncontrollable situation. But the show does not stop.

It goes on when you try to use display instead of visibility. In order for any element to have a programmatically fetchable size and position, it must have display value other than none. My .css changes this value in runtime, on mouse over.

Remember those three bits again and add this one. Apparently IE can’t do class switch in time for the repos and WCH scripts, so they happily return zeros or nothing for the submenu’ size and position. Lovely. You try to fix one problem and bump into another. And another. It never ends.

I tried several tricks.

Changing the position using JS, not CSS, did not helped at all. It behaved the same. Changing WCH to check the runtime value of display property (and if it is not, to force it) yielded very interesting results: returned value was block, but it behaved as it is not. This was too much.

All in all, this is one hell of a mess. Use it as you dare, on your own risk. Be prepared to anything. And please report back any ideas and solutions you might have.

Drop-up menu

Sat, 01 May 2004 21:51:54 +0000

Due to popular request (hi xeon :), I have updated the examples with the drop-up version. This is useful if you want to place the menus in the page footer.

This is the only important part:



/* fix the position */

#menu li ul {

	bottom: 1.5em;

	left: 0;

}

#menu li li ul {

	bottom: 0;

	left: 100%;

}

1.5em is just an example value. You need to modify it according to menu make-up (as shown in the examples).

Good to have in mind is that usability script will not be much help here, as it checks for menu going below the viewport’s bottom, while here we need to check for going above the viewport’s top. I will make sure that future revision of the script deals with this situation. It’s not hard, I just need to find time to do it.

There is one more change, due to some wierdness in IE 5.0x on Windows. I had to use display instead of visibility because the latter creates huge problems in IE. Main menu is totally broken, probably because IE is acting like the submenus are not absolutely positioned at all. This way, wierdness is limited only when item is hovered.

Also, I gave the better explanation how to extend the styles to have more submenu levels, in the pure CSS menus post.

csshover.htc and IE freeze

Mon, 19 Apr 2004 19:33:52 +0000

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.<strong>iehover</strong> {

	...

}

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.

Vertical menu examples

Mon, 19 Apr 2004 13:07:04 +0000

I received several e-mail requests to create vertical examples of the menus. During the Easter holidays I did them, but had no time to write event the shortest entry afterwards. (Is it just me or the amount of work that piles up while being on any holiday is so big that quickly burns any freshness from it?)

So, not to delay this anymore, I have created vertical examples.

Changes are few. What I did was to move the basic CSS rules used for submenus to the main menu as well, and re-style the main menu so that it sits comfortably at the left side.

#menu li { margin: 0; padding: 0; border: 0; width: 100%; display: block; float: left; position: static; } html>body #menu li { float: none; position: relative; }

<strong>#menu li:hover</strong> {
	position: relative;
}

<strong>#menu li ul</strong> {
	top: 0;
	left: 100%;
}

#menu {
	...<strong>
	width: 120px;
	height: auto;
</strong>
}

Stronged parts are the essential changes. Rest of the changes in the actual menu’s CSS is just designs. You should make sure, as shown above, that height is not restricted and that width is restricted, because the LIs have 100% width.

ADxMenu2 - the usability script

Tue, 09 Mar 2004 16:22:19 +0000

There are situations when the drop-down multilevel menu will go outside the visible area of the page. It is either too long or has two or three sub levels (I certainly don’t recommend more than that).

Such menu is highly unusable and there are two solutions:

Re-arrange the layout elements so that menu fits on the page in reasonable space
Apply the script that will reposition the menu

Script dependencies

Calculating element position on the page is still in the art-form stage. Browser line in use today is not always up to the task. Sad thing is that you can’t check for certain element or property and be sure that script will work. Buggy or partial implementation of certain elements is the real problem. A problem that leads to ugly browser detection.

For example, Gecko browsers have complete (in terms of what I needed so far) positioning support from version 1.5 (Firebird 0.7). Previous version were fine when you used CSS-P purely. If you look at this example you will see that sub menus appear where they are supposed to.

But when you want to set the position through DOM, you have problems as illustrated in the following figure. 1.4 version of Gecko core is used by the last Netscape-branded browser (7.1) so this problem is here to stay. :(

Apple web kits prior to version 101 (I think) also have this problem, so Safari 1.0 and Omniweb suffer from it. Safari 1.2 is fine and I hope that final version of Omniweb 5 will fix this as well. Additionaly, it does not work in Opera 7.23.

Problem is that, when you do object.style.left = "0px", that 0 is not the (0,0) point of the positioned parent, but that of the whole page (of body).

So, this script must check the browser version to make sure that everything would work as expected. That is one major dependence.

Another is technical. Previous version of ADxMenu was dependent on three other scripts. In this version, I removed all of them.

Onload execution

In the previous version, I used AttachEvent script to do necessary work on page load. I like that script because I know the order of onload-scripts execution. ADxMenu is not dependent on the order anymore, as the basic menu functionality is achieved using only CSS.

This entry is updated (May 6th) to be compatible with latest ADxMenu.

Therefore, I could safely use event listeners already existing in the browsers (you’ll shortly see what ADXM is).

if (window.addEventListener) {

	window.addEventListener("load", ADXM.Init, false);

} else if (window.attachEvent) {

	window.attachEvent("onload", ADXM.Init);

}

if (window.addEventListener) {

	window.addEventListener("resize", ADXM.Viewport, false);

} else if (window.attachEvent) {

	window.attachEvent("onresize", ADXM.Viewport);

}

It also acts as yet another browser detect.

DOM library

As before, I use X library from Mike Foster. Only this time I moved the functions I use to the ADxMenu script. If you use X-lib for anything else and have it already included in the page, then just delete that part of the script.

Drop-down field problem in IE/Win

You are certainly aware of the problem with form drop-down fields showing through the layers. I have recoded the menu script so that it checks for existence of WCH functions before it calls them. That way, you can include or not include the WCH script - menu script will work either way. It is good not to include it if you don’t have drop-downs or other windowed controls on the page (saves one HTTP request and some download time).

Usage

I have simplified the way script works (or so I believe). During page loading, it will create an object, ADXM, that has certain properties and methods.

How to use it?

Include the script in the page, and add your menus with lines such as this:

ADXM.Add( "menuList", "H" );

menuList is the ID of the main menu UL element. Second parameter defines whether main menu is horizontal (“H”) or vertical (“V”).

Update: If you are using WCH along with menu script, each UL in the menu must have an unique ID. Without the IDs, WCH will not work as expected. Kudos to Koen Calliauw for reporting this back.

How it works

All added menus will be processed on page load. Viewport size will be saved (this is also done on each resize). Then script process all menu items and adds appropriate handlers to sub menu actuators.

On hover, it calculates the position where menu should be, and then checks for available space until the bottom and right viewport edge. If there is not enough space, it moves the submenu in the opposite direction.

Take a look at the examples - follow the “full script” links. Please report any positioning problems you encounter.

ADxMenu2 - pure CSS multilevel menus

Sat, 06 Mar 2004 17:34:23 +0000

A new way to accomplish multilevel menus without the Javascript. Peter Nederlof has created a behavior that adds arbitrary :hover support for IE/Win. That means that IE will now recognize li:hover, thus giving us more degrees of freedom for menu creation.

That means that basic functionality does not depend on user’s preference regarding Javascript. You can include the script only if you want to add additional usability features: off-screen positioning check, as well as placing menus over drop-downs (WCH).

I have slightly changed the way CSS is built. All of them now depend on li:hover. Peter’s behavior deals with IE’s lack of support, but only on windows. That means that ADxMenu 2 menus will not work in Mac IE, Opera 6 and any other browser that doesn’t fully support :hover pseudo-element.

Major improvement: this CSS finally solves the “phone-book” problem in IE/Win, and sub menus can be normally repositioned, not one over another.

Pure CSS menus

First rule is to include the behavior (with proper path, relative to the .css file).

body { behavior:url("csshover.htc"); }

Then we remove the default list rendering and reset all box properties to 0. List items are floated to the left and positioned relatively, to define new coo-system for their child elements (sub menus).

#menu ul {

	margin: 0;

	padding: 0;

	border: 0;

	list-style-type: none;

}



#menu li {

	margin: 0;

	padding: 0;

	border: 0;

	display: block;

	float: left;

	position: relative;

}

A elements are transformed to blocks. For the sake of, and only for, IE/Mac, they are also floated to the left, using famous backslash-commented hack. All sub menus are absolutely positioned.

#menu a {

	float: left;/* */float: none;/*  */

	display: block;

}

#menu li ul {

	visibility: hidden;

	position: absolute;

	z-index: 10;

}

The next part is crucial to avoid “phone-book” problem. Sub menu list items are pos:relative for anything but IE. This way, there are no new z-index “spaces” and sub menu will not go under the remaining items in the parent menu. Only when the sub menu is about to be displayed, its parent item is going pos:relative, allowing …

#menu li ul li {

	width: 100%;

	display: block;

	float: left;

	position: static;

}

html>body #menu li ul li {

	float: none;

	position: relative;

}

#menu li ul li:hover {

	position: relative;

}

…correct placement. Without the li:hover support, this is not possible. Peter deserves eternal gratitude for this.

#menu li ul li ul {

	top: 0;

	left: 100%;

}

Unfortunately, there is no way to simulate the child selector, also needed for nested menus. Therefore, we need to cheat a little.

div#menu li:hover ul, #menu li:hover li:hover ul,

#menu li:hover li:hover li:hover ul {

	visibility: visible;

}

#menu li:hover li ul, #menu li:hover li:hover li ul,

#menu li:hover li:hover li:hover li ul {

	visibility: hidden;

}

That first div is needed for IE5.x support. Last version of behavior should actually work without the actual node name specified. And it does in IE6. Also in some simple cases in IE5, but not in this. Strangely, adding just one node name solves the problem. Peter said to me that it must be some error in .htc, but I believe that it’s some IE5.x quirk.

For advanced browsers, that understand child selector, use it instead of the code above. This part can actually be removed, but I deliberately included it to show the proper way how this should be done.

#menu ul#menuList li:hover > ul {

	visibility: visible;

}

That is all. This is enough to make the menus work. Rest of the styles is up to your CSS and designer skills. Take a look at the examples I provided.

Read the next ADxMenu entry to learn about the script that will reposition the menus if they go outside the visible window area. It also incorporates WCH2 script which helps with yet another IE/Win problem.

Update (May 1st): After few questions in the comments, I realized that I haven’t explained the logic behind the IE simulation of child selector. So, here it goes.

How to add more submenu levels for IE

If you look at the unstyled version of the list, you can see that, when particular item is hovered, we want the first nested list to appear, and all deeper nested lists to be hidden. This is possible with child selector - it will take all elements inside of the li and fetch just first ul it encounters:

#menu li:hover > ul {

	visibility: visible;

}

In example list, when mouse is over Products, browser’s CSS engine will find that li and then start to process all elements inside of it. It first finds a, skips it, and then finds ul, applies the style to it and stops.

Since IE doesn’t support this, we need to simulate it. Look at this:

#menu li:hover ul {

	visibility: visible;

}

#menu li:hover li ul {

	visibility: hidden;

}

Look at the HTML code for the list and work it out down the nesting. #menu starts it up and then goes to process all its children. It skips the ul for the main menu, and then finds the Products list item. li:hover ul means “find all UL elements inside of this LI and apply the style to all of them”. And thus not only Products submenu is visible, but also Categories and Hardware. So we need another rule to leave Products visible, and hide those that are nested deeper.

The other rule has one more li before the ul. That means that browser will find all ULs nested inside each list item in the Products submenu and hide them.

To be simple and clear: when you load the page, only main menu is shown. When you mouse over Products item, first rule will show all possible submenus - for Products, Categories and Hardware. What we actually need is just Products submenu to appear. Second rule makes sure that Categories and Hardware submenus are hidden.

For deeper levels, you need to repeat this rule pair and each time add one more li:hover just after #menu. Here is how it looks for one level down (Categories).

#menu <strong>li:hover</strong> li:hover ul {

	visibility: visible;

}

#menu <strong>li:hover</strong> li:hover li ul {

	visibility: hidden;

}

Since I have 3 submenus (main menu is not counted), in all .css files I have 3 pairs of rules.

Or, to cut the long story short - number of li:hover is identical to submenu level.

Going cross-platform

Mon, 08 Dec 2003 11:30:09 +0000

This revision of the script & style is rather small (hence the small version increment) but it adds important compatibility with Mac browsers. I’ve tested it on Mac OS 10.3, in Safari 1.1, IE 5.2.3, Firebird and Camino 0.7, Opera 6.03 and OmniWeb 4.5. Also tested on IE 5.1.7 on Mac OS 9 but very lightly as it appears that that one has identical behavior to 5.2.3. If you find differences, please let me know.

CSS is slightly changed, and simplified in a way; more like streamlined, free from unneccesary style rules. I also returned WinXP style example - it needed change in IE-related script to work properly. Fixing this has side effect that item icons can be used again.

I provided download links for each example menu style, so you can play around and reuse them.

Script changes

Mac testing revealed some not very pleasant things. Safari had problem with the main style rule, repeated here (for full style review, checkout previous post):

    #menu {
    	position: relative;
    	z-index: 10000;
    }

In some cases it wrongly reports the distance from viewport top to the menu as document.clientHeight(?!), which then screws up the check for off-screen placement. Since that style rule is only needed for IE/Win, I added * html in front of it and now it works OK for IE and not causing problems for any other browser. To be sure that Safari does not break ever, I added this line of code to positioning part of the script:

    if (ADXM_ua.indexOf("safari") != -1) return;

OmniWeb uses the same engine as Safari (KHTML), but it has more problems - it reports item width as 0. :( To my surprise, Camino is doing the same (while Mac Firebird works great). So, similar lines as the one above are added at the begining of ADXM_SetMenuPos() function.

As you can see, I have returned the XP Luna style to the list of examples. To achieve the effect, I need li:hover. Since IE/Win doesn’t support that, I added this to the script:

    oMenuLI.onmouseover = function() {
    	this.className = "over";
    };
    oMenuLI.onmouseout = function() {
    	this.className = "";
    };

Suckerfish drop-downs use the same stuff - class change is a very powerfull tool. It’s not very standard-oriented, but since we are using it simply to simulate standard behavior, it can pass.

Now you simply need to style li.over identically as li:hover and you’re all set.

Style changes

I have reworked the styles for Basic, Minitabs and WinXP example. They are now as simple as possible. Important change is the addition of this:

    #menu li ul li:hover > ul {
    	left: 30px;
    }

Because JS positioning is turned off in some cases, that means that submenus are placed right below parent item. In the vertical menu, that means that submenu will cover remaining items in the parent menu. This rule makes sure that submenu leaves some room, so user can select lower parent menu items. As one of the example shows, this rule has no effect in Camino 0.7. I figure this is a bug, so I’ll leave it be.

And there’s also Opera 6. Whether on Mac or Windows, horizontal menu with width:auto is going veeery wide. So this ugly bit of style rules is needed to fix that:

    /* Fix for Opera 6 */
    html>body #menu li { width: 67px; }
    /* undo for CSS2-compliant browsers */
    head:first-child+body #menu li { width: auto; }

It gets worse in some cases, like in WinXP example where I needed to fix the submenu width (and widths of its LI elements). But, that’s the price of backward-compatibility. Personally, I would prefer to simply ditch Opera 6 support; unfortunatelly that involves server-side detection.

Yipi

OK, that’s it. All that’s left to do now is follow browser changes and fix what ever gets broken. I believe that bad times are behind us, and that future browsers will offer much better CSS2 support.

Update

Small update for better browser support. After tests with Netscape 7.1 and PocketPC 2003 IE, I realized they don’t support menu re-positioning functions as well, so I added exit lines for them too. (Dec 10, 2003)