The menu script is incredibly well encapsulated, and uses only
two permanent global variables - "um" and "umTree",
and two global functions - "umIni" and "umNav".
The chances of conflict are very low, in fact I'm only
aware of two potential issues:
Internet Explorer 5 for Mac
doesn't support the way the script initializes, using a
DOM element as a trigger reference.
So for this browser (or if the trigger element can't be found),
the script will fall-back on a regular window.onload handler.
But it's as sensitive as it can be
to whether your page already contains
this handler, as it uses a closure around any existing
onload functions before adding its own,
thereby ensuring that all such handlers will be honoured.
In practise this means that if you're using
window.onload, and you want both it
and the menus to work correctly, then your event-handler
must come before the
udm-dom.js
script include. If it comes after, the menu
will not initialise for this browser or failsafe situation.
You can always use a <body onload> handler safely,
since it will inevitably be before the menu script.
If you add custom event-handlers to the menu list-items they will probably not work, because the script already uses most of the common events as expando properties of those items. Add your event-handlers to links instead, or use the UDM API.
All comments subject to administrative approval. Comments may be deleted or modified by the site administrator.
UDM 4 is valid XHTML, and in our judgement, meets the criteria for WAI Triple-A conformance.