More advice for the full screen mode.
Sivut toimivat riittävän hyvin MS IE 4.0+, Opera 5.x+, Netscape 6.0+/ vast. Mozilla ja Konqueror 3.x selaimilla. Yleisesti ottaen sivut toimivat parhaiten uusimmilla Opera selaimilla. Sivujen toimivuus vanhemmissa selaimissa on heikko, erityisesti Netscape 4.x kohdalla.

I list below all topic groups, which I have done according to subjects, which they handle. You can return to this topic group by using this menu and the link Table of topic groups on the top of the each page.



Visibility & position

In all other browsers than Netscape 4.x the positioning base on CSS and In all DOM/DHTML capable browsers properly supported properties and property values are position:absolute, top and left. In addition of these authors must define the stacking order with the z-index property, where higher value means higher position in the stack. The default visibility value for dynamic menus is in general for the main menu visibility:visible and for sub-menus visibility:hidden. These values will be altered with JavaScript.

If menus are intended to close through the content both for the base element and the actual content should be set the z-index property in order to get stacking order relative to the whole Web-page. If the base element of menus doesn't have the stacking order any following element in the content, which has the z-index property should set above the menu. Stacking order values for elements inside the base element of menus remain internal.

At this way positioned element don't affect anything to the positioning of other elements. For example the effect of position:absolute; top:50px; left:50px; width:600px; height:400px; visibility:hidden is in practise the same as if for the element has been set display:none. Hided and positioned links don't take any space of the other content of the document.

The system, which I have explained can be used in all situations, when elements can beforehand set exact positions. The most typical solution is a drop-down-menu, which I have handled in this Web-page. The advance of this solution is that opening of menus newer cause need of redraw the whole document or most of it. In my solutions only defined menus will be revealed in the positions, where they really are in the page! Even if menus will be generated "on fly" they will not affect anything to the positions of other elements in the page - only the speed and/or reliability is different compared to links, which already exist in the page.

Because I have from the same basic menu several versions I collected groups according to the horizontal or vertical positions of menus (the names of menus and values of properties are today different as in the example):

/* horizontal positions and x-index for second level sub-menus */
#Generic, #MainPages,... {left:128px; z-index:19;}
/* horizontal positions and the z-index for third level sub-menus */
#MainPages, #Appendixes, #Generic1,... {left:266px; z-index:20}
/* vertical positions for all menus */
#Pages, #PagesEn,... {top:42px}
#MainPages, #Generic1,... {top:59px}

I have used in my examles multi-level sub-menus. Instead of multi-level sub-menus it would be possible to use indented links for lower level pages - compare alternatives with two screen capture images[S].

Browser-specific notes:

  1. MS IE renders elements, which have visibility:visible as visible even if they are inside elements, which have visibility:hidden. This is the correct behavior. Opera hides always and new Mozilla Gecko (for example Netscape 6.1) browsers if position:fixed has been used hide incorrectly these kinds of elements (a test page[S]).

  2. In first dynamic menus previous mentioned properties didn't always worked in these Netscape 4.x browsers, which I have tested. That's why I have in all cases given in the example pages corresponding attributes for LAYER elements. The LAYER element doesn't have the position attribute but in the previous example <LAYER top="66" left="141"> means in theory the same as position:absolute; top:66px; left:141px in CSS (and for example z-index="3" means the same as z-index:3) - indeed Netscape positions elements a little bit differently as MS IE and Opera. Because LAYER elements are proprietary I use them only generated by scripts.

  3. I recommend to read my generic advice[S], when it is possible to avoid big problems.

In the most advanced browsers could be used also the position:fixed positioning type. This way positioned menus are accessible in all situations. Using position:fixed cause on remarkable limitation to the designing because the only reasonable system is that the main menu is vertical. Menu items are under each other. If a wide horizontal main menu is used all anchors cause problems because the menu hides the beginning of the content. The visitor should scroll page always a little bit upward when internal links have used - he would be soon as an angry wasp and he would swear very much!

If there might be a situation, that the menu could hide some content, it should be the possibility to hide the whole menu[Pw]. Of course there should be also a link to show the hided menu again. Below are some images, which could be used to hide and the main menu. They are on the left side of the screen capture of a dynamic menu, which use them.

Nature pages

Hiding and showing menus could also set as full or half-automatic. In the latter case onmousedown for the main content should close the whole menu. It would reveal then on the (left, right of both) sides of the page active areas, which have onmouseover to reveal the menu again.

Browser-specific notes:

  1. It can be defined with attribute selectors, when MS IE doesn't understand it but it would work in new Opera and Mozilla Gecko browsers:

    div.pageGroup, div#allPages {position:absolute} div[class="pageGroup"], div[id="allPages"] {position:fixed !important}/* Because attribute selectors have lower weight than id-selectors, in the the declaration must use the !important rule. */
  2. The system doesn't work ideal in Opera 5.x-6x (works properly starting from Opera 7.0 Beta 2) and not at all in MS IE 5.0 for Mac. It works ideal only in new Mozilla Gecko browsers (read about deficiencies closer from the page, where I handle the functionality of browsers[S] in my sites; I made also a test case[S] in order to demonstrate problems)

  3. Instead of fixed positioned elements is is possible to use with JavaScript-encoding implemented elements, which "float" with some delay to their positions. The functionality is worse than fixed positioned elements. I handle these kinds of elements in an extra page[S].
  4. Even if Netscape 6.0 doesn't support the position:fixed type I found that it works according to the position:absolute, when this solution didn't cause those problems with Netscape 6.0, which I expected.

  5. I have sometimes seen elements, which stayed in their positions. Because browsers moved elements upward/downward the functionality was not very good. I can't teach scripts, which implements (at least partially) fixed elements. Below is a Web-address to the menu Top Navigational Bar IV (ver. 3.3.19) by Andy Woolley. That menu works with certain setting stable in most browsers (including Opera 5.x-6.x) and it follows scrolling (with default preferences the menu in unstable in Opera 5.x-6.x and Opera 5.x has difficulties to download the JavaScript).

    Setting in the script menu_arrays.js for the menus for example ,,120,1,,style1,0,"left",effect,1,,1,,,,,,,,,, menus stay visible and they follow the scrolling until another sub-menu has been selected. In multi-level menus the behavior is in most browsers quite bad because sub-menus follow the parent menus with irritating delays. The functionality is much worse than position:fixed in Mozilla Gecko browsers. The most reasonable usage for this kinds of links is few link arrows, which go to the top of the page (a model page[S]) and previous/next page. Indeed with Opera 7.x also multilevel menus in the Milonic Web-site of Andy Woolley work quite well (much better than in MS IE 6.0 for Windows) and Opera 6.x (the menus doesn't however start working as soon as in Opera 7.x). That site use an updated version of the previous mentioned menu (the version, which I downloaded was 3.5.08 but today it is presumably newer). Opera 5.x can't always download the version 3.5.08 and if Opera can download it, ver. 3.5.08 doesn't fit for Opera 5.x. In order to solve this problem it necessary to write a script so that Opera 5.x gets the older version (look at the source code[S] of this page). In general the basic problem of these kinds of menus is that menus are available only if the JavaScript support is enabled. It would be a better solution to build the basic structure of menus by using server-side programming, when the menu would be at least at some level available also in situations, where the JavaScript support has been disabled. Try to create dynamic menus with PHP[S].

  6. The problem that menus might be over the content could in principle ease also by setting the transparency with the opacity property, which belongs to CSS3. With Netscape 6.2+/ Mozilla 0.9.4+/ at least as new other Mozilla Gecko browsers can use the -moz-opacity property, which is a temporary implementation of the opacity property.

  7. With Opera could test also other positioning types than top-left, but the functionality is in other browsers is weak. I don't recommend to use bottom-left, top-right and bottom-right positioning types. Individual links or small link sets can be positioned according to them but not dynamic menus.


Other alternatives

If menus will be defined in the same place and the same size, in principle they can be implemented instead of changing the values of the visibility property with the changes of the values of the z-index property. I don't however how wide this alternative works.

The weakness of both visibility and z-index based solutions is, that they don't fit for menus, where the position of elements can't set beforehand. An example of these kinds of menus is the Explorer of Windows, which I have a screen capture below.


Because the menu can be expanded in any situation, the vertical positioning can't be defined beforehand. Elements should be able to hide/ reveal by changing between display:none and display:block. If elements have display:none they behave as if they don't exist at all in the page. When they have display:block they clear space for themselves.

This solution has a great disadvantage if for the menus has not been reserved at all or for them has been reserved insufficiently space to expand. Opening of menus can cause continuous need to reformat the document. This slow down the performance of the browser and it might crash it. As I have written changes of the display property don't work in Opera 4.x-6.x browsers. If I have understood correctly, because of previous mentioned reasons Opera Software has been decided, that Opera 4.x-6.x browsers don't accept dynamic changes of the display property. In my mind changing of the display property in frame free Web-sites is overall a bad solution even if Opera 7.x+ and other modern browsers support them.

Menus, which resemble the Explorer fits in my mind only into frame documents, where the menu is in its own frame - also the Explorer works in this principle! The corresponding system can be achieved with Java applets, for example with products of Auscomp. The disadvantage of Java applets is that they are slow and many browsers don't support them as default. The JRE of Sun Microsystems is a big plug-ins application in order to download with modem connections! It is possible to create dynamic menus also as Flash-animations. In addition of products of Macromedia it is possible to create them also with other application. I have no experience creating dynamic menus with them.

Auscomp, Macromedia, Sun Microsystems.

Advantages and disadvantages of Flash- and applet menus:

Menus are relative easy to implement inside frames also by creating "on fly" with JavaScript of server-side encoding a total new menu page, when the visitor has been clicked a link of a sub-menu. These kinds of menus work also in Opera.