In addition to the dynamic menus, this tutorial covers some additional features that are discussed below.

The events associated to the roll-over images use the common onMouseOver trigger, albeit in a different manner. While most people use it within the <A HREF="....html"> tag, I use it inside the <IMG SRC="....png"> tag to take advantage of passing the actual image object handler to the imgOver(imgHndl) function: no type of indexing or naming of the IMG object is needed because the IMG handler is available.

Changing the image's source property is just a matter of adding/removing the "ov" suffix in the file name, if the convention mentioned in Functions: dm_func.js is followed.

The onMouseOut trigger is required to restore the image to its default condition, once the pointer moves away. It removes the "ov" suffix from the image's source filename.

Notice that if you use images for the menus, you should put one onMouseOver trigger inside the <A HREF="....html"> tag to show the menus and a pair of onMouseOver, onMouseOut triggers inside the <IMG SRC="....png"> tag to roll-over the image.

An alternative way to achieve the "roll-over" effect uses the StyleSheet possibility to change the property of a link when the pointer hovers over it. The code below effectively creates a hover effect on text links inside the <TD class="tab"> and <TD class="tabm"> elements.

td.tab a { color: #ffffff; text-decoration: none; }
td.tab a:hover { color: #000000; }
td.tabm a { color: #ffffff; text-decoration: none; }
td.tabm a:hover { color: #000000; }

You should be cautious with the properties you change, since they may change the page layout. For instance,

td.tabm a:hover { color: #000000; font-size: xx-large; }

will yield odd results - to say the least.

I believe this solution is simpler than the image roll-overs and it doesn't require the download of additional files from the server.

The page layout of this tutorial is very simple and favours reading on the web. If you like it, you should consider using the following rules when designing your own site:

1. Text is sparse, since reading on-line is more fatiguing than reading on paper.
2. There is a blank area on the left for the eyes to rest while scanning the page. I sometimes use it on the right, too.
3. Text is divided in short clear sections to help you navigate through the content, without scrolling too much.
4. The page layout takes advantage of the whole screen width: if you have a short monitor, you will have to scroll, if you have a large screen, there is no point in scrolling down, while a large white area stays vacant on the right; therefore, the page contents stretches to the screen limit.
   
5. There are few decorative images - only one per page, in fact - to keep download times down and prevent users from being distracted.

The possibility of changing the size of the fonts is perhaps the most misinterpreted feature of a web browser. Many designers reject it and most users ignore it. Nevertheless, you should welcome this feature since it is essential to users with poor sight.

The possibility of locking the font size appeared with StyleSheets and even before that, some designers were using images instead of text to choose the font face, size and other attributes, regardless of user preferences.

I acknowledge that web design is a creative work and the author should have the possibility to define his/her work, namely the presentation of the fonts. And for an analogy, the user can't change the typeface or the colours in a paper magazine or the size of the letter on a TV set (he should buy a larger TV set, instead).

Nevertheless, the fact that the Web allows such possibility should be regarded as an advantage and not a nuisance. If you lock the font size, the user will be forced to lower the resolution of the screen - in case this is possible - to view a site with letters too small lo read.

The current tutorial uses a font size definition that welcomes font size changes. Unfortunately, different browsers have some differences in the interpretation of font size definitions:

Internet Explorer 6

The definition in pixels, font-size: 14px; , locks the font size, while the definition in points, , font-size: 14pt; , doesn't.

Netscape Navigator 7 (and Mozilla)

The definition in pixels, font-size: 14px; , or points , font-size: 14pt; , unlocks the font size, but the scale of the size changes is different.

Transparent backgrounds and semitransparent backgrounds in dynamic menus are often a poor idea, unless you can control the content of the <BODY>...</BODY>, below the menus.

I tried to illustrate this problems in the "Images" and the "Features" menus (experiment hovering the pointer on these menus):

Transparent background

In the "Images" menus, the background of the entry under the pointer is transparent. This effect is not to discredit image based menus; I could also achieve it with text based menus.
As you may see, it is harder to read the menu entries and the last one is nearly invisible due to poor contrast. In fact, I used transparent backgrounds only in the "ov" image (see Roll-over images) to keep it legible.

Semitransparent background

In the "Features" menu, the table background is formed by a checkers pattern, 50% coloured, 50% transparent.
It appears to be more legible than the other one, but still the user comfort is diminished without any perceived benefit.

In spite of its disadvantages I used this effect in the one case where the beauty of the design was at stake. In my album of photos of Belgium I used semitransparent backgrounds for the dynamic menus but I had to reinforce the weight of the menu entries to keep it legible. In the same album, I use transparent background for the arrows that move between images, but in this case, the symbols are unambiguous and occupy a fixed position on the page.