Hi Yannick,
It seems that you're running into the menu system's built-in "anti collision" mechanism (or whatever they call it). If a menu is going to open in a place where one or more of its edges will be clipped by the browser window, the position is automatically adjusted to avoid clipping (or avoid collision with the browser edge).
I suppose Andy could introduce another global parameter that could be used to turn anti collision/anti clipping off. But that would require more work on his part, with what I'm sure is already a long to do list!
Barring that, Ruth may be on to another potential solution. There are several internal functions that could probably be used to position the submenu manually, relative to the position of its parent item in the main menu. That'd take a bit of recoding of how your main menu opens submenus and would require some creative application of javascript. Do you or one of your colleagues know js well enough to tackle the task?
Another possibility occurs to me. It seems to me that the anticollision methods do not come into play when opening a submenu from a
horizontal main menu; if the bottom of the submenu would be clipped by the bottom of the browser window, and that submenu does not have overflow=scroll set, then the bottom simply gets clipped and a vertial scrollbar appears in the browser window. So... you could try redefining your main menu as four separate, horizontal main menus, each containing only one item, and positioned to appear as one vertical main menu. Don't know if that'd work (and haven't tested it), but I suspect that it would. One caveat... I don't know if the lack of collision adjustment for submenus opened from a horizintal parent is by design or an oversight. If by design, then no worries. If it's an oversight, and you get it to work that way, then you run the risk that the oversight will be corrected in a future release, and you'll be hosed when you update.
One other problem occurs to me. Suppose you do thwart the anticollision. You say that the user would then scroll down the page to see the rest of the menu. Seems to me that would only work if he or she used a mouse wheel to scroll the page, so that the pointer would remain in the menu to keep it active. If the user moved the pointer to the browser window's scroll bar, the menu would close because the pointer left it; the user would then have to re-open the menu... is that what you want? One possibility to negate that effect would be to use the menu's keepalive property, but I personally find that to be a little bit of a pain.
One final comment (yes, I'm feeling long winded, as ususal). Personally, I have liked the appearance of your submenus from the first time I saw them: it's cool the way you've positioned the submenu so that it's image aligns with the image in the parent item, to preserve the pink button as part of the overall menu effect. It's clear that you take pride in the look of the menu, as well you should. But you have to go to an awful lot of work to do it, and now you have even more work with this latest twist. I wonder if the site would suffer much if you just bagged preserving the pink button and opened a plain ol' rectangular submenu? I say this especially given the site's content: I doubt that the typical member spends much time admiring the look of the menu when there are clearly other aspects of the site to be, um... well... admired.
Just a thought.
If you are intent on keping the button look, you might try the multiple horizintal approach first, and see if that works for you. If not, the manual positioning is still an option.
Cheers,
Kevin
anyways, try going right away to 
and i thought there simply already was a setting in the menu program! 
