Aleksandar • Vacić

iOS bits and pieces

Work in progress...

A lot happened since the last ADxMenu post.

I was working further on the script, primarily looking for a way to work properly in IE 5.x on Windows. IE5 and IE6 are probably 98% of end-users, so this was my primary target, while keeping all CSS2-compliant browsers happy.

I had just finished version 1.5, when several things happened.

First, there was a huge discovery that IE 5, IE 5.5 and IE 6 can work side-by-side, which simplified testing. Then, Suckerfish dropdowns article appeared on ALA, which spurred excellent discussion about the possible problems and solutions.

Toni Anzlovar sent his take on nested menus, and someone posted Peter Nederlof’s script.

All of them suffered from the IE-phone-book problem, but that is easily resolved by relatively positioning the menu itself (while keeping it in the body element). Which resolved only part of the problem. Each of these scripts uses the following technique:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
li {

  ...

  position: relative;

}

li ul {

  ...

  visibility: hidden;

  position: absolute;

}

#topNav li:hover > ul {

  ...

  visibility: visible;

}

This is the basis of it - each LI element is RP or AP, and then use top and left properties to position the submenu where needed. Greatest benefit is that menu functionality is achieved with 0 bytes of Javascript in CSS2-compliants.

While this is great, it inevitably leads to this bl**dy IE-phone-book problem, as demonstrated here.

overlapping layers in IE

pos:relative or pos:absolute for each LI places its child UL in that item’s z-index space. This means that nested menu will be drawn below the next item in parent menu and not above, as you want it to.

In this example, submenu of Register new card is going below Deposit funds and Withdraw funds items.

What to do?

Not much. There’s simply no good solution for this, and we can only compromise, doing something of the following…

  1. Don’t use RP LI elements, and use fairly complicated positioning which can’t really be cross-browser (like ADxMenu 1.4 and unpublished 1.5 do).

  2. Carefully layout pages so that menu always stays inside of 700px (800x600 screen)

  3. Don’t care about whether menu goes off-screen (ignorance-is-bliss approach)

Yup. It su*ks.

I also started using RP list items in the first installment of ADxMenu, but abandon it after encountering the problem. That lead me to a script which was becoming increasingly complicated to develop and maintain. Fixing one issue in particular browser enacted another in some other browser.

Therefore, I reverted to the beginning, following the lead of other developers in the next version. Check here for ADxMenu 1.6 where I explain the solution I opted for.