Developer's manual

Some of this is only directly relevant if you're using the original javascript configuration - if you're using a server-side configuration then you don't need to go through the manual generation process. But I do still recommended that you read it - particularly the stuff lower down, from Behavioral differences when scripting is disabled.

Generating a noscript stylesheet

The menu styles are created with a set of CSS-generating algorithms inside the udm-style.js script. You can also run this script independently of the menu, and use its algorithms to generate pure CSS. This useful capability means that once your design is finished you can generate a plain stylesheet from your configuration file, and use that instead of the script-generated stylesheet.

The practical drawback is obvious - the stylesheet is static, so whenever you change your design you'll have to re-generate it manually (which is why there's no point doing it until your design is finished).

The practical advantage is also obvious, and far outweighs the drawback - for people who visit your site in a CSS-capable browser but with javascript disabled, your navigation bar still looks the same :)

Run the CSS Generator

In your udm-resources folder there's a file called css-generator. Open it in any fully-supported browser, click the Generate CSS button, then paste the generated code into udm-style.css (also in the udm-resources folder).

The CSS generator reads udm-custom.js for configuration data - if you want it to use a different configuration file, simply change the applicable <script> src in the generator page's source code. The program compiles onload, so when you change or edit the configuration file, you have to refresh the page afterwards.

Change the style include

Once you've generated the stylesheet, remove udm-style.js:

<script type="text/javascript"

and add udm-style.css in its place, either with a <link /> element:

<link rel="stylesheet" type="text/css"
	media="screen,projection" />

or an @import statement:

<style type="text/css" media="screen, projection">
	@import "/udm-resources/udm-style.css";

As far as the script is concerned, it makes no difference which you use; however if you use @import in that format it will hide the CSS from Netscape 4 and IE4.

If you'd rather not use an inline <style> block (because browsers which don't understand it will write out its contents as literal text) then you can put the @import statement at the top of another, <link>-ed stylesheet. That's what I generally do.

Please do not put HTML comments inside a <style> block - this is a bad habit we should all get out of - a validating parser is not required to read comments, much less process them, so commented style rules shouldn't work at all; and indeed, in the XML DOM, they don't.

Notice how I've used "screen, projection" for the media - that's because Opera in fullscreen mode uses projection-media CSS, not screen. It may also be useful because the comma-delimited syntax is not understood by Netscape 4 - it will not process the stylesheet at all.

A note about image paths

If you're using images in the menu, and you have the image-path variable um.baseSRC set to a relative path, you will find that with a plain CSS stylesheet in the udm-resoures folder, all the image paths are broken. That's because relative paths in CSS are from the location of the stylesheet, not the page.

The easiest way to solve this is to use an absolute path for um.baseSRC, but if that's not possible there's a couple of alternatives:

  • change um.baseSRC to a path that's relative to the stylesheet, generate your CSS, then change the value back; or
  • move the stylesheet out of the udm-resoures folder and keep it in the root folder instead (at the same level as the page).

Behavioral differences when scripting is disabled

For graphical browsers there are no menus when javascript is disabled. There are also some other (comparitively minor) aspects of the navbar's behavior and appearance which cannot be maintained without scripting:

  1. rigid horizontal overflow - a horizontal navbar will be flexible.
  2. javascript emulation of position:fixed - if fixed positioning is used it won't work in Win/IE.
  3. the appearance of internal headings in a horizontal navbar in Win/IE5.0 - the widths of heading elements in a horizontal navbar have to be set with scripting; if this can't happen you'll see a slight gap between each link, as though the list-items had a small amount of padding-left.
  4. the horizontal continuation strip in Mozilla Gecko builds 0.9.4 (Netscape 6.2) or earlier - the strip has no height without scripting, and will therefore not be visible.
  5. dynamic z-index of navbar links - when using border collapse with border rollovers, the full integrity of highlighted borders cannot be maintained.

Access for screenreaders is unaffected by scripting support, providing you use static menu creation.

Behavioral differences when styles are disabled

When CSS and scripting are both disabled, the navigation tree appears in its plain state - as an unstyled list of links, equivalent to what a legacy or text-only browser would see.

When CSS is disabled but scripting is enabled, the navigation list will not be dynamic: this is an unusual circumstance, but nonetheless possible, and without special consideration you would get unstyled lists with open/close behaviors - unuseable at best, and certainly not pretty.

So the script includes a check for this - it will stop responding to events and remain static in the state it had before CSS was disabled. However Safari, and Opera versions earlier than 7.2, cannot get the properties needed for this check, therefore in those browsers the original potential issue remains.

Access for screenreaders is unaffected.

When colors are turned off

Win/IE has an accessibility option to Ignore colors specified on Web pages. All colors are removed as though no author-colors had been defined, and so the link and menu backgrounds become transparent. A similar thing happens with the Use High Contrast option in Windows' Accessibility Options control panel - author colors are replaced with a high-contrast color-scheme, so overlaid elements become transparent.

Transparent menus are no use - they're all-but impossible to read or navigate - so for the sake of overall usability, in these browsers at these settings, the menus won't be there at all.

Access for screenreaders is unaffected.

More about the CSS Generator

The generator program has capabilities beyond its companion use - in fact it can create the CSS for pretty much any list-based navigation bar you care to design! Please see Getting more out of the CSS generator for more about this amazing feature.


We would like your feedback! Take the UDM4 Survey!

UDM 4 is valid XHTML, and in our judgement, meets the criteria for WAI Triple-A conformance.