Aleksandar • Vacić

iOS bits and pieces

Going cross-platform

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

1
2
3
4
#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:

1
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:

1
2
3
4
5
6
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:

1
2
3
#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:

1
2
3
4
/* 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)