Milonic JavaScript Menu

2. I write XHTML, with a valid doctype, and the menu works for me.

Writing a document with the XHTML doctype is only part of the equation. A true XHTML document is served like an XML document with application/xhtml+xml because it is an XML document. Now if you're writing plain html pages, then it ...

It works (otherwise the menu wouldn't for those of us who write XHTML), it just doesn't validate.

Mentioned, but not 'documented'. Got a better link?

What? You should really read up on the XHTML spec. The problem with the menu can be demonstrated pretty easily. Add this to the top of your ...

The use of document.write in the menu should be replaced with DOM calls. This is a problem when building XHTML pages on a server that serves the correct xhtml mimetype: application/xhtml+xml

The problem is documented here:

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

Here's the good one:

_menuCloseDelay=100;_menuOpenDelay=100;_menuOpenDelay=100;_followSpeed=5;_followRate=0;_subOffsetTop=10;_subOffsetLeft=-10;_scrollAmount=3;_scrollDelay=20;retainClickValue=1;fixMozillaZIndex=true;
with(RootMenuStyle=new mm_style()){
borderstyle="solid";fontsize="12px";fontstyle ...

Actually it looks like $S.width=$T really should be changed. It looks like this value gets set when no menuwidth is set. $T doesn't already have "px" appended to it, so that really is a bug.

This menu is a bit quirky when declaring px values. In some places, it's allowed and in those cases required and in other places, if you declare it, it breaks what it's supposed to be setting. For all values that can have px appended to them, the menu should intelligently check to see if the px ...

Never mind. I'm retarded. I forgot to put in px after setting the values myself. Perhaps a possible enhancement would be to get the substr of the last two characters of the value and if they're not "px" and the value is not empty, then append px to the value.

Seamonkey 1.0b and Firefox 1.5 complain about missing px declarations in the latest version (5.738) of the menu.

Here are the offending lines:

_fsize=(_I[12]?";font-Size:"+_I[12]:Z$);

->

_fsize=(_I[12]?";font-Size:"+_I[12]+"px":Z$);

in $z function:

$S.width=$T

->

$S.width=$T+"px";

I don't know where to report bugs so I figured I would report it here. With the new Gecko 1.8 code (Deer Park and Seamonkey Alpha and the old Mozilla 1.8a/b), the javascript console can now report css errors. One of these errors exist in the $z function in the last statement of the function:

$S ...

Thanks for the info but this deals with menu positioning more than followscroll. The problem is that the spos function cannot override the menu position when followscroll is set. It has nothing to do with whether or not I implemented followscroll properly.

I know the spos function works for alwaysvisible menus. It just doesn't work for alwaysvisible __and__ followscroll menus. When followscroll is set, the menu disgregards spos and prefers the default top and left coordinates which are set within the "root" alwaysvisible followscroll menu. The menu is ...

Your suggestion to use the spos function does not work for menus which utilize followscroll. It seems there aren't any errors relating to the (undocumented?) BDMenu function anymore (5.728) but just to test, I took out the function again and it seems to have no impact on using your function to ...

It seems your function breaks the menu causing it not to load at all on version 5.726. It was working on 5.718. For some reason Andy decided to remove if(_W.buildOffScreen) from the from the g$ function. buildOffScreen I believe is a global variable to remove flicker or something. Anyway it's gone ...

The popup function didn't sound like something I needed but I did find your function:


function mm_changeMenuProperty(menuName, propertyRef, newValue)
{
var menuNum = getMenuByName(menuName);
_m[menuNum][propertyRef] = newValue;
BDMenu(menuNum);
}


It's a great function and mm ...

Sample 24 is probably the closest to what I'm talking about but it only functions for submenus which limits you for menu options. I'm a bit surprised that with all the menu options there are that this one a little overlooked. The need for this is pretty great for such things as cached google ...

I was just curious if it's possible to load the menu using absolute positioning based on the coordinates of a reference element id like a div tag? You would then specify the offset from that reference element so the menu could be loaded at those coordinates.

1. Get top and left position of ...

Actually I figured out what the issue is. There needs to be a menuheight option for the menu to have overflow scrollbars on the root menu.

I did some testing and there seems to be a direct correlation between the scrollbars not appearing and the menu being set to alwaysvisible=1. So it does not matter if it's the main menu or a sub menu. Overflow="scroll" simply does not show scrollbars when that particular menu has the alwaysvisible=1 ...

I grabbed the menu from milonic since you need something to look at. As you can see the scroll bar does not appear on the main menu but it does appear on submenus in which overflow="scroll" is specified.

http://members.cox.net/~faramir/


Someone might want to check out my other post as well which ...

I am guessing that this is a bug but scrollbars don't appear when setting overflow="scroll" on a really long vertical main menu (submenus work fine).