This list covers technical questions about using and configuring the menu. If you have more general questions about the capabilities of UDM, please visit the General FAQ.
"none"
[OR] How do I prevent other
page CSS
from affecting the menus?
Yes, you can add individual widths by addressing the navbar links
and list-items from external
CSS - for example
give each one a class
or id
attribute, then set the widths from
a normal stylesheet. Please see the
Individual item widths documentation for more information.
Yes, in the same way - you can add individual widths using
<ul>
style attributes or by addressing the
menus from external
CSS. Please see
Styling the menus externally for more details.
You could also use the Auto-sizing Menus extension to have the menus size themselves automatically.
Yes. One way is to put <img />
tags directly inside the links,
but a better (easier and cleaner) way is to use an image-replacement technique,
as detailed in the
Making an image-based navbar documentation.
In it's regular configuration, the menu script can only support a single navbar and menus.
However, the script also has a popup menus mode, where the navbar is not rendered at all, and menus are triggered from events on other page elements. Using this mode you can have any number of menu structures - you build the navbars, and the script will generate menus for them. For details please see: Using popup menus
But you'll still need to create some navbars, and one way of doing this is to use the CSS-generating program that comes with the script. This is documented in the article: Getting more out of the CSS Generator
Native cross-frame functionality is not supported, however you can create the appearance of menus going across frames by using the script's popup menus functionality, to have a navbar in one frame trigger menus in another. For details please see the Popup menus across frames example.
The configuration file doesn't give you such specific control over menu offsets - you can set a default offset between the navbar and menus, but otherwise it's determined automatically based on the position of the trigger.
You don't need to worry about menus going below the fold - they automatically reposition themselves so that they're always inside the window.
But if you do still need this capability, you can do it by capturing menu-open commands using the UDM API, then repositioning them yourself.
"none"
[OR] How do I prevent other
page CSS from affecting the menus?
Since the navigation structure is normal HTML, it will be affected by global styles applying to its component elements. There's a number of things you can do to avoid this being an issue, discussed in the Potential CSS conflicts documentation.
This issues was fixed in 4.3 - please download the latest version.
Yes you can - please see Print-media CSS for details.
Most of the component scripts have been stripped of unecessary comments
and whitespace - this makes them much smaller, and therefore faster loading.
But the main configuration file (udm-custom.js
or
udm-custom.ini
) is fully
spaced and commented, and that's the only script you need to
edit.
You shouldn't try to edit any of the other scripts. If you want to add to or modify the menu behaviors beyond what's available in the configuration file, you can do so using the UDM API.
You can have full transparency using the colorname
"transparent"
for link or menu backgrounds.
But partial transparency (opacity) is a problem for
Internet Explorer ...
In theory you can use its Alpha Filter, however IE clips elements which are filtered, and since UDM is a true heirarchical menus (where child menus actually are child elements) you will find that for any menu to which you apply opacity, none of its children are visible. So really you can only apply this filter to a menu which has no child menus. This also applies to PNG backgrounds, which require another proprietary filter to have opacity in IE, which in turn re-creates the original clipping problem.
Only IE has this issue - you can use the standard
CSS
opacity property, or the proprietary
-moz-opacity
and -khtml-opacity
implementations of Mozilla and
recent KHTML browsers, and they'll work fine.
You could also have the menu transparent, and use its dropshadow layer as the background - a filtered PNG wouldn't be a problem there since the shadow layer has no descendents. However there are several browsers that don't support the dropshadow, and so for them the menu would end up completely transparent.
In short, there is no cross-browser way of having semi-transparent menus, but there are several less-than-perfect approaches.
<ul>
menus go before
a closing </li>
, not after it.
onclick
. For details please see:
Menus that open onclick
Yes, all the navbar and menu items must be anchors
- text directly inside
<li>
is not allowed, because plain-text items
would not be accessible to the keyboard.
But if you want an item that's just a submenu trigger,
and not an active link, you can do this by creating the link
with the class
name "nohref"
instead
of it having an href
, like this:
<a class="nohref">
The script will manage those so that they remain accessible, without them doing anything else. However you shouldn't have non-link items in the main navigation bar, only within menus, because for some unsupported browsers, the navigation bar may be all they have. For details please see: Non-link menu triggers.
Thanks for Lisa Neuman for this answer:
The "bin" folder in IIS 6 is now defined as a .NET system folder. Any unsigned script or executable placed into that folder will not be called by the server - errors will not appear in the log, the scripts just won't execute. So if the scripts for your menu are in a folder called "bin", either rename the folder or move the scripts, and then it should work okay.
Those are not actually JavaScript errors, they're CSS warnings, which the browser is reporting over syntax it doesn't understand.
This includes proprietary code like "filter"
and "expression"
for IE,
and CSS3 syntax such as
media queries,
all of which are used as hacks for various browser quirks.
These can't be removed without undermining the layout
for one or more browsers (including Firefox itself).
But really the browser shouldn't be reporting these as errors at all - they're not errors, and they're certainly not JavaScript errors. I reported this to bugzilla but it seems unlikely to be fixed, so if it bothers you seriously I suggest having a look at the console² extension, which provides greater control over errors and warnings in Firefox.
You can use the form below to search through the manual:
Or the advanced search form.
With our in-depth knowledge we can save you time and money in development.
UDM 4 is valid XHTML, and in our judgement, meets the criteria for WAI Triple-A conformance.