This is the main page of the tutorial. If you are new to Dynamic HTML read the following sections. If you feel comfortable with layers and event handlers manipulations, skip to "How it works" and then to the Files' descriptions.

In the Images tab, the use of images on menu entries is discussed. Additional and optional features are also included.

Finally, you can also send your feedback on this tutorial or find more about similar pages.

Dynamic menus are a very comfortable and efficient manner of multiplying the navigation aids on a site.

When you first enter a site, browsing through all the pages in a section might be tedious, so a shortcut is welcome to get closer to your goal. Moreover, if you are an experienced user of a given site, the dynamic menus will give you a tool to move faster around the various sections.

However, dynamic menus should always be regarded as a enhancement to the navigation scheme, not a replacement. You should keep all your pages accessible through regular links, do not depend on dynamic menus.

This tutorial emphasises the value of multiple platform compatibility. You should reach the broadest possible audience with a single design instead of developing different versions for different platforms. In the latter case, the costs will rise sharply, the features available on each platform will diverge over time. Probably, you will have insufficient resources and you will end up maintaining only the most relevant versions.

Modularity is the key to efficient web design. Developing, maintaining and upgrading a web site is much easier if it is composed of modules. When an update is requested, you only need to change a particular file instead of revising a whole site. Sure it imposes some restrictions on the page variability but this is a negligible cost compared to the efficiency gains.

In this example I used three modules (see Files):

• the style sheet,
• the menu functions and
• the menu contents.

The HTML pages call on these modules to implement the menus. In case a new menu entry is needed, only the menu contents file is changed.

DynamicHTML (DHTML) first appeared in 1998, based on Cascading Style Sheets and JavaScript 1.2. Netscape Navigator 4 and Microsoft Internet Explorer 4 were the first releases to implement DHTML, albeit in two different forms that forced the web designers to duplicate the code (at that time, NN had approximately 80% of the market share and IE had 15%, but it was already apparent that the support for IE would be decisive in the near future).
Years later, the World Wide Web Consortium (W3C, www.w3c.org) issued a Document Object Model (DOM) specification, the two main browsers adhered to it and now the code is again unified.

If a browser can't read the style definitions (usually in a *.css file), it won't be able to render the DynamicHTML layers. Moreover,JavaScript 1.2 was introduced to deal with layers (the core of DHTML) and more powerful event handling. If a browser doesn't know to interpret JavaScript 1.2 it will not run the scripts.

When you consider to embed DHTML in your design, these are the mains constraints that must be observed:

Earlier browser releases

Netscape Navigator 3 and Internet Explorer 3 and earlier releases could not read the DHTML code. When I started using DHTML in 1998, this concern was logical since most web users had earlier releases, so they could not take advantage of the dynamic menus. That's why I always keep a link on the dynamic menu root (in this case: Tutorial, Files, Images, ...).
Nowadays, most computer browsers can deliver DHTML but there is a wide range of new devices - such as cellphones, Personal Digital Assistants, televisions, screens on vehicles - used to browse the Web and possibly without showing DHTML.
Using the modular approach provides a side benefit: since the DHTML code is stored on modules, if the browser can't read the modules, it won't load the code, saving download times and wrong interpretations. If the content of the layers were to be included in the HTML page, it would be rendered as regular HTML by early browsers that were very forgiving on the syntax.
Thus, the <link rel="stylesheet" href="dm.css" type="text/css"> is ignored by a browser that can't run stylesheets as well as the line <SCRIPT LANGUAGE="JavaScript1.2" TYPE="text/javascript" SRC="dm_func.js"></SCRIPT>, if it can only read JavaScript 1.1.

Disabled features

In some cases, the support for stylesheets and JavaScript is disabled by the user for security reasons or to fight some computer annoyances, such as cookies and pop-up windows. If DHTML is really necessary to your site, make sure to inform your audience that CSS and JavaScript must be enabled.

Cross platform sites

Very likely, your site will be accessed from a broad range of platforms. Try to avoid browser or platform specific solutions that will go awry on other platforms. You can't impose yourself perfect results in all platforms but you should aim to display decent results in nearly all platforms, even if the result is less than excellent in some of them.
Quite often, the web designer is not aware of the different implementations, that's why it is important to test your site with different computer/browser pairs.
An example from my experience: using partial transparent backgrounds in tables with NN 4 yields opaque results. With IE, I found no bug.

User strangeness

For most users, the main metaphor of the web is a page. And pages don't change when you move your finger over them. So, for many users it may be odd to find that "something" pops up when they move the pointer over a link. Thus, make sure the dynamic menus are clearly recognisable.
Some people move the pointer fast while others are slow (they may be using a device other than the mouse, for instance), so the menu must be visible long enough for the users to read all the entries and move the pointer to their desired location.
Some users will pass the pointer over the menus while looking for something else. If someone is trying to read or to follow a link that gets concealed by the menu, he/she will be irritated with the new technology.
That's why the menus should be automatically hidden after a few seconds. That's also why I do my best to keep the area under the menus clean of links. Now you know why the background image goes below the menu line.

Screen size

It is now a current assumption that users will have access to large screens, with a resolution equal or larger to 1024 x 768. I think this is a wrong assumption, especially for sites targeting a wide audience on the Internet. If you're making an Intranet site for a company you may assume certain features about the users' hardware, otherwise you should be conservative. There are users around the world using older computers or newer mobile phones, television "set top boxes", PDAs, game devices, etc..
I usually design for a resolution close to 800 x 600, while showing the main contents in a 640 x 480 window. Thus, the navigation aides should be constrained to the first 600 pixels, approximately. Having this said, I try to accommodate the design to the screen width: if the user has a wider screen, he/she will take advantage of it, otherwise, it will be necessary to scroll...
Naturally, this principle does not apply if you're creating a web design piece of art. Be aware, though, that you are restraining your audience by setting screen size constraints.

Screen constraints

Be attentive to colours, contrasts, transparencies, animated and blinking elements and don't rely on colours to carry essential information: some users are colour-blind, while others are using grey scale displays.
Don't invest too much in graphical elements, such as non-rectangular frames, decoration bars, and complex graphics. They look very nice if you're using a large screen and regular font sizes, but try to reduce the window or to enlarge the characters and you will get frustrated soon.
Usually, a strong contrast based on black over white, or white over black achieves the best results. Some people dislike white and they prefer light grey (e.g., #f0f0f0) or a light colour cast. You should avoid middle brightness backgrounds (e.g., #808080) for text pages since it reduces your contrast margins.

If you're creating a plain informative site, I suggest you pay a visit to www.microsoft.com, www.ibm.com, www.yahoo.com and www.reuters.com, for instance. These are large companies that need to prove nothing on the web design market and they focus on serving content to their clients. You don't need to have a different web design to reach your audience. You need to serve your clients the content they are looking for.

The state description of the dynamic menus is straightforward:

0. In the default condition, the menus are hidden, only the title links - with the main sections - are visible.
1. If the user hovers the pointer over a title link, the correspondent menu is shown.
2. If the user clicks one of the menu entries, the browser follows to the specified destination. If a new page is open, the dynamic menus return to their default condition. Otherwise, the menu remains visible until one of the following two conditions is met.
3. If the user hovers the pointer over a new title link while an earlier menu is visible, it is hidden prior to displaying the new menu.
4. If the user fails to take any action regarding a visible menu after a specified time lapse, the menu is automatically hidden and the page returns to the default condition.

After these rhetorical remarks :-) let's see how the dynamic menus really work.

Each layer is composed of a portion of HTML code wrapped in a <DIV ID="dynmenuX"> ... </DIV> block. The ID contains the name of the layer. The code in a layer is similar to the one you add to a regular <BODY> ... </BODY> section.

The position of the layers is specified in the stylesheets (check StyleSheet: dm.css) and it is fixed. The only operation performed is to display or hide the layer via the visibility property.

Each layer contains a menu, each menu entry links to a different destination.

I usually use a table to format the layer. The table has a WIDTH specification but no height specification to accommodate different number and length of menu entries. If you include the NOWRAP argument within the <TD>...</TD> tags the lines will stretch beyond the specified width to avoid wrapping the line. This will also occur if you use a long word or graphic element that is longer than the specified WIDTH . Finally, if you're using text it may grow over the WIDTH limits if the user decides to increase the fonts (and he should be able to do it in order to read properly). In one sentence, the WIDTH specification is a minorant of the actual table WIDTH .

In this example, each layer is a table with 134 pixels width, minimum, and the total of the layers takes a minimum of 134 x 5 = 670 pixels. In some cases the layers locations might overlap but the layers never do, since before displaying a given layer, all the others are hidden (check Functions: dm_func.js).

The event handling in this example are quite simple. Only three types of events are considered.

Show the menus

The dynamic menu is made visible when the title link (the title on the tag) is hovered by the pointer (most often, the mouse pointer). This is performed through the event trigger <a href="....html" onMouseOver="showMenu(0)">. The showMenu() function just changes the layer visibility property to " visible " and sets a time-out to eventually hide the menu.
There is no onMouseOut trigger to keep the dynamic menu visible once the pointer leaves the title link. Otherwise, the menu would disappear the moment the user moves the pointer away from the title tag, towards the menu. The menu is hidden by JavaScript if another title link is hovered and a new dynamic menu should be made visible (check Functions: dm_func.js) or if a new page is loaded, since in the initial condition sets the dynamic menus' visibility to hidden .

Time-out to hide the menu

In addition to the two previous cases, the dynamic menu is also hidden by a time-out. The time-out is launched when the menu is made visible. It is set to hide the dynamic menu 8000 millisecond later if the user fails to take any action with the dynamic menu. Otherwise, the menu would remain permanently visible, possibly upsetting the user.
This time lapse must balance the user competence with dynamic menus - which would make it shorter - with the time the user takes to read the menu entries and move the pointer - which would make it longer.

Image roll-overs

This event is not related to the dynamic menus; it is discussed in the additional features page.

One final notice about the time-outs: if a time-out expires when it is no longer required (to hide a menu that is already hidden, for instance), the browser usually ignores it, since web browsers are very forgiving. However, it is good programming policy to clear the time-out if you know it won't be necessary (because you're hiding the menu within the code loop, for instance).
On the other hand, if you clear a time-out that there is no longer set, the command is ignored, so you don't need to query the existence of a time-out prior to clearing it in the beginning of hideMenu(idx) (see Functions: dm_func.js).

I hope this introduction has been useful to you. Feel free to examine, copy and change the code to meet your needs.

One final statement about of how you should be using DynamicHTML (DHTML): when I go to Microsoft's site with Internet Explorer I get dynamic menus with shortcuts to the inner sections of the site, whereas I go with a Mozilla browser I don't see any dynamic menus at all. Nevertheless, I still can navigate the site, using the title links. My point is not whether Microsoft's policy of not supporting other browsers is appropriate.

My point is that your site should be fully accessible without DHTML. Use it as an enhancement only. If you are uncertain how your site works without DHTML and you don't have an old browser, you may switch off JavaScript on your regular browser and try to navigate your site.

It is true that portions of my sites do require DHTML. However, these were not intended for information purposes; they were created for the sake of amusement and beauty.