Developer's manual
- Manual →
- Final steps →
- Generating a noscript stylesheet
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
- Change the style include
- Behavioral differences when scripting is disabled
- Behavioral differences when styles are disabled
- More about the CSS Generator
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"
src="/udm-resources/udm-style.js"></script>
and add udm-style.css in its place,
either with a <link /> element:
<link rel="stylesheet" type="text/css"
href="/udm-resources/udm-style.css"
media="screen,projection" />
or an @import statement:
<style type="text/css" media="screen, projection">
@import "/udm-resources/udm-style.css";
</style>
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.baseSRCto a path that's relative to the stylesheet, generate your CSS, then change the value back; or -
move the stylesheet out
of the
udm-resouresfolder 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:
- rigid horizontal overflow - a horizontal navbar will be flexible.
- javascript emulation of position:fixed - if fixed positioning is used it won't work in Win/IE.
-
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. - 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.
-
dynamic
z-indexof 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.
