Agreed on the small submenu issue. I think this instant behavior makes the most sense when it's always the case that submenu.height() == menu.height().

Was pointed to http://michelf.ca/blog/2005/mac-sub-menus/ by @gecko this morning, which brings up the opposite (and legit) problem: very, very long submenus.

Mega dropdowns w/ equal submenu height are a nice use for this, though.

Single-item submenus and super-long submenus are to be avoided at all costs. They are not user friendly. The former has no reason for being -- put the contents in the parent menu as a sub-section. The latter is generally found in auto-generated lists, like lists of fonts or countries.

Usually a menu is a bad UI device for selecting from very long lists. Combo boxes are one alternative. Breaking contents up into chunks and adding another level to menu hierarchy is another possible solution. MS-style hiding rare choices is a third option.

Single-item submenus inevitably occur at some point if the submenu is filled out programatically (as smackfu pointed out). A list of recently open files is a good example. While it's possible to move the single item into the parent menu, that would make the menu confusingly inconsistent.

I think part of making this solution intuitive is to make the submenu box a a fixed height that's equal to the first menu. It's what the author changed his menu to look like as well. Amazon got around having too much empty a space by adding pictures, and too many submenu options by adding a second column. If your submenu is so long that even 2 or 3 columns isnt' enough, it would have been too long for a single column anyway.

Set up the submenu system so in the event of a single line, it presents an invisible target, which is three lines high, with the submenu in the middle.