Hello. I'm Aleksandar Vacić, professional web developer and wine maker in the making.
Learn more about me or see what I can do for you.

My work & services

ADxMenu v4 — flyout (drop-down) menu

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:

  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 12-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:
  1. <!--[if lte IE 6]>
  2. <script type="text/javascript" src="ADxMenu.js"></script>
  3. <![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:

JavaScript:
  1. // li:hover
  2. oLI.onmouseenter = function() {
  3. this.style.position = "relative";
  4. this.className += " adxmhover";
  5. };
  6. // li:blur
  7. oLI.onmouseleave = function() {
  8. this.style.position = "static";
  9. this.className = this.className.replace(/adxmhover/,"");
  10. };

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

CSS:
  1. .adxmhover ul,
  2. .adxmhover .adxmhover ul {
  3. visibility: visible;
  4. }
  5.  
  6. .adxmhover li ul,
  7. .adxmhover .adxmhover li ul {
  8. visibility: hidden;
  9. }

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.

Mouse events

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.

Mouse events

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…

tags: ADxMenu
Comments: 10

Posted 3 years, 8 months agopermanent link

trackback URL: http://aplus.rs/adxmenudev/adxmenu-v4-flyout-drop-down-menu/trackback/

Voices from the crowd, 10 so far

Aleksander, to say I appreciate your continuing work on ADxMenu would be a HUGE understatement. That having been said, I have a question regarding your examples. Is the issue I’m seeing in IE7 your “IE7 bug 1″ doing its damage? When I look at the code I see neither the problem CSS or the solution CSS, so I am wondering why it is still happening, or if this is a separate issue completely.

Screen capture:
http://img285.imageshack.us/img285/6927/adx4htbgifuk0.gif

by Michael Tucker
1 day, 21 hours after the post

Michael thanks for sending that screenshot. At first, I tried and could not replicate this in IE7, but with enough switching back and forth between apps it finally appeared just like in your screenshot. It’s very strange. It does not shows up always. When it does, it lasts just until its parent item is hovered again. After that IE7 does not render it that way at all.

Inability to replicate it properly is a pain to debug, but I will see what I can do.

by Aleksandar
1 day, 22 hours after the post

Man, this is just…#$Q#@$&*&!!!

I know how to replicate it. Open any menu example, move your mouse over ADxMenu, then Examples and then to the left, off the submenu. Move mouse around, hover ADxMenu menu again — there it is — second menu still rendered. If you move the mouse from the Examples up or down to another item, and then off the submenu, bug is not triggered.

I can sense what is happening and I’m certain it is connected with the changes they did with background property, because only the ul and li elements are rendered, but not a. Whatever they did with background, they should have left as it was.
And when li:hover expires, they do not hide all nested list individually but only the top. That is why it is not triggered in the second case, because moving from Examples to Instructions hides the 2nd level submenu. If I immediately leave from the Examples, it hides whole 1st level submenu, and thus the second as well, but it is not setting display:none on the 2nd level. Aargh!

Real sh*t. :(

by Aleksandar
2 days, 18 hours after the post

Moving the background: url(empty.gif) from IE6-only style to main style .menu ul {} seem to have prevented this bug from showing up in the case explained in my previous comment (when Examples in 1st level submenu is offed).

But, it still shows up if the 2nd level nested submenu is offed. Beh… will try to solve that later. Definitely a background painting related bug.

by Aleksandar
2 days, 18 hours after the post

I may have something on this. I have managed to avoid this bug in IE7 by changing the .menu ul {} and .menu li:hover>ul styles from “display” to “visibility”. This makes the menu work perfectly in IE7, even with four sub-levels. Of the browsers I have to test with, for both Mac and PC, the only browser this change seems to have a negative effect on is Safari 2.0.4, which definitely doesn’t like the change :)

I am not an expert at conditional CSS, but it seems a quick fix would be to create an IE7-only style using visibility rather than display.

What do you think?

by Michael Tucker
6 days, 22 hours after the post

Hi Aleksander

I just read (an old) post of yours about finding a way to make the menus know when they were off screen and force to to reposition themselves.

Have you found a solution to this?

I’ve been trying a few things with Suckerfish, but IE7 doesn’t want to behave properly (for some unknown reason).

Regards

by Matt Stow
1 week after the post

Michael, you are correct, it works just fine with visibility. What I need to do now is to resolve the positioning trickery for various cases (bottom right placement of the menu, for instance) to avoid unnecessary appearance of scrollbars.

by Aleksandar
1 week, 4 days after the post

Matt, my old menus had that covered, in Enterprise version. At least for IE6 and Firefox. I have not worked on that for 1.5 years, thus can’t help. If I get to do that, there will be a post, for sure.

by Aleksandar
1 week, 4 days after the post

New version posted with mentioned problems resolved. Closing comments on this one.

by Aleksandar
3 weeks, 4 days after the post

[…] Sitio web del desarrollador: http://aplus.co.yu/adxmenudev/adxmenu-v4-flyout-drop-down-menu/ […]

by Lombardi » » Menú desplegable con ADxMenu
1 year, 4 months after the post

Comments are now closed. I probably thought there was nothing more to say.

Tags or categories or topics...

Lots of ramblings on this blog...might be easier for you to find your juice through these tags:

Post a job. Find one. authenticjobs.com