How should anyone know their widths if you don't say so and the main parent is absolutely positioned??
Also, why are you hiding the submenus from screen reader users? (they are aware of stylesheets, and they do honour display: none... and since they do not use the mouse, they will never get display: block)
It looks like this is a vertical menu with a right-sided fly-out?
What I would do:
Set the #menu itself to position: relative with no coordinates. This allows it to be given a z-index for if you get into trouble with IE and any relatively-positioned stuff coming after the menu. Otherwise, you don't even need positioning at all. It'll be a block by default and therefore will be 100% width of its container by default, so as a vertical menu, you'll want to set a width. When you absolutely-positioned it, its width was set by the content inside, as abso-po'd and floated boxes shrink-wrap to inline-content width. This means if you have multiple words anywhere, esp with - or / in them, you should get different widths per browser as they will wrap at different places.
Set the first-level li's to position: relative and either leave them display: block OR float them (whichever doesn't give you a whitespace bug in IE).
The direct main-level anchors then will need to be floated to prevent IE whitespace bug. Set any floated li's and/or anchor's widths to 100% to be as wide as the menu and set no sidepadding/sidemargins (remove any defaults from the browser).
Now the subs:
set them to position: absolute. Their nearest-positioned ancestors are the main-level li's, so when you set top and left (or right) on them, it will be relative to the li's. I tend to set the Left and Top to something close to 0 and use margins for the actual placement... I think for IE's benefit, I forget.
The submenus will be set initially to a margin-left negative number like -999px so it is off-screen yet available to screen reader users who surf with CSS on (as most people do). I set them in px so they can come onscreen with the keyboard... for some reason em's don't work.
When the main-level li's are :hovered (for keyboarders, say when the main-level anchors are :focussed, + siblings come onscreen... this would be the sub ul), the left-margin position changes to a positive number (and something wider than teh width of your menu). This brings them onscreen for visual CSSers.
With the submenu's being absolutely positioned, and their li's and a's inheriting float, you will likely want to set whatever width you want on the subs and you might want to remove float on the sub li's (so they become display: block). This should stop them from stretching across the page (if that's what they're doing??? wasn't clear).
You shouldn't need to use px in the JS but you can if you have set your menu width in px. Again, I only use px on margin/coordinate settings because it seems to be the only thing that works with :focus with CSS.
BTW if you would like to see a different variation of using JS for delay on a dropdown, check this one out.
It does have a Gecko bug that's not fixed, but it's still useful to see what he did.