[Top]
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.
 
 
Search:
[Help]
Table of topic groupsFront page of CSS-guideExtra pagesI How to design dynamic menus > Solutions for problematic situations (section 1/6)

Solutions for problematic situations

Because DHTML/DOM1 works at different level in browsers, in my mind DHTML/DOM-based menus should build so, that pages work also in such browsers, which don't support DHTML/ DOM scripts. Pages should work also in situations, where the user of the browser has turned off the JavaScript support. I have found situations, where without the JavaScript support doesn't exist at all working linking system. There is two reason for that matter. Either links have been generated "on fly" with JavaScript or they are hided (they have as default either visibility:hidden or display:none). I regard both solutions as bad. Links could be visible if the hiding would have done by using the onload attribute for the BODY-element. In this case links are visible if JavaScript has been turned off. This solution doesn't however work, because in dynamic menus links overlap the main content and maybe also total or partial each others.

In my mind following solutions are better:

  1. Main links work in all browsers and by using them it is possible to go to pages, which have continuation links. In this solution DHTML/DOM menus concern only sub-menus. In this case it is not relevant, if sub-menus have been automatic generated by scripts or they exist in the page, but scripts just hide/show them. It is not harmful, if a part of links are always hided, if the JavaScript support has been turned off.

    Browser-specific notes:

    1. It is not possible to solve all JavaScript and server problems, but if the presentation is not depending on the situations, if JavaScript support is enabled/disabled the visitor doesn't wonder, why the presentation changed quirky. At that mean this alternative is the most reasonable.

  2. Menu-related LINK elements are generated with JavaScript. At this way it is easy to tailor CSS for different browsers. Below is some examples of possible solutions:

    <script language="JavaScript" type="text/javascript">
    <!--
    function linkStyle(sStyleFile,sStyleMedia)
    {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
    href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}
    /* Shortening code by using a function. In later scripts the file name and the media type has been give as arguments of the function. */

    if (document.layers)
    {linkStyle("layersNetscape4.css","screen");}
    /* This is a condition for Netscape 4.x browsers, which don't support DOM1, but which support proprietary DHTML. For Netscape 4.x browsers should not set several values for the attribute media (for example screen,print).*/

    else { /* CSS for other browsers. Netscape 4.x has difficulties with complex conditional statements. It is best to give for it the simplest possible conditions. */
    if (document.getElementById) /* This test, if the method which belongs to DOM1, is supported. This is a condition for all such browser, which support in the used script the DOM1 section (under Windows it is supported in MS IE 5.0+, Opera 4.x+, Netscape 6.x+ / corresponding Mozilla browsers). */
    {linkStyle("layers.css","screen,projection");} /* Opera needs the media type projection. Future PDA-browsers might need also handheld.*/

    else if (document.all)
    {linkStyle("layers.css","screen");}
    /* This is a condition for such MS IE browsers, which don't support DOM1, but which support proprietary DHTML. Because the used file is the same as in the previous condition, the condition could be combined with the previous test by using the format (document.getElementById) || (document.all). */

    else if (!(document.layers) && !(document.all) && !(document.getElementById)) {linkStyle("noLayers.css","screen");} /* For unknown browsers, which don't support either proprietary DHTML or standard DOM1. If they support CSS, they get static link tables without layers. In this case these conditions are unnecessary but this is an example of using excluding conditions. */

    else {} /* A formal termination of this block. This statement-block is not necessary but it is a good practise to end conditional statements a this way. */
    }
    //-->
    </script>
    <script language="JavaScript" type="text/javascript">
    <--
    /* In this example most browsers have been detected on the base on browser-specific informations. */

    function linkStyle(sStyleFile,sStyleMedia)
    {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
    href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}


    var IE4, OP, Gecko; /* It is a good practise to list global variables. */

    IE4 =(((navigator.userAgent.indexOf('MSIE')!=-1) || (navigator.userAgent.indexOf('Internet Explorer')!=-1)) && (navigator.userAgent.indexOf('Mozilla\/4.')!=-1)); /* Because newer MS browsers identify as Mozilla/4.0 compatible this detection fits also for newer versions. Some versions of MS IE use instead of the string MSIE the string Internet Explorer.*/
    OPua = (navigator.userAgent.indexOf('Opera')!=-1); /* Generic detection of Opera browsers. */
    op_pos=nua.indexOf('Opera'); /* Get the desired string. */
    OPnu=nua.substr((op_pos+6),1);
    OPnu2=nua.substr((op_pos+7),1);
    /* At first has been defined, where to start counting digits after the desired string. The number 1 tells the quantity of used digits. In some identification strigs of Opera 5.x+ for Symbian OS (EPOC) browsers before the actual version number might be the letter v when the format (op_pos+7),1 is needed. */
    OP=(OPua && ((OPnu>=4) || (OPnu2>=5))); /* Detects Opera 4.x or newer browsers. In this case numeric values has been compared on the base of the previous variables (Opnu and Opnu2). Opera browsers can detect also by using detection strings like ((navigator.userAgent.indexOf('Opera 5')!=-1) || (navigator.userAgent.indexOf('Opera\/5')!=-1) || (navigator.userAgent.indexOf('Opera\/v5')!=-1) || (navigator.userAgent.indexOf('Opera v5')!=-1)). If for example Opera 5.12 for Windows would be in the mode Identify as Opera it would give the string Opera/5.12 and in other identification modes it would give the string Opera 5.12. Because dynamic menus work properly staring from 5.x+ it would be reasonable to ignore Opera 4.x browsers. */
    Gecko = (navigator.product == ('Gecko')); /* The detection for all Mozilla Gecko based browsers. It is possible to use also the same kind of detection method as for MS IE browsers above (navigator.userAgent.indexOf('Gecko')!=-1). */

    if (document.layers)
    {linkStyle("layersNetscape4.css","screen");}
    /* CSS for the dynamic menus for Netscape 4.x browsers. Detecting Netscape 4.x browsers by creating variables from the identification strings doesn't work. */

    else {
    if (IE4||OP)
    {linkStyle("layers.css","screen,projection");}
    /* The CSS for dynamic menus for MS IE 4.0+ and Opera 4.x+ browsers. */

    else if (Gecko)
    {linkStyle("layersGecko.css","screen");}
    /* Total new or added CSS for Netscape 6.x+/ corresponding Mozilla browsers. The need of an own file is very small. If this section is not needed, the detection can be combined to the previous condition by writing it (IE4||OP||Gecko). */

    else {}
    }

    //-->
    </script>
    <script language="JavaScript" type="text/javascript">
    <!--
    /* A combination of method and browser based detections. You can support the widest possible range of unknown user agents if you test their feature availability. At least primary detections should base on supported methods. Only a part of the detection should base on the name of the browser or other browser-specific information. */

    function linkStyle(sStyleFile,sStyleMedia)
    {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
    href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}


    if (document.getElementById){

    var OP, Gecko;
    OP =(navigator.userAgent.indexOf('Opera')!=-1);
    Gecko = (navigator.userAgent.indexOf('Gecko')!=-1);

    if (OP)
    {...}

    else if (Gecko)
    {...}

    else
    {...}
    }

    else if (document.all)
    {...}

    else {}

    //-->
    </script>

    Browser-specific notes:

    1. If it is necessary to detect the MS IE browsers more exact that in the previous examples, that can be done for example by using conditions like (navigator.userAgent.indexOf('MSIE 6')!=-1). Instead it is a bad idea to use the version number based detections, for example navigator.appVersion.indexOf("5.")>=0. In addition of the version number of the browser itself, it might mean also the version number of the compatible Mozilla, platform (for example Windows NT 5.0) or the version number of the deliverer of the browser (for example AOL 5.0). A possible identification string might be for example Mozilla/4.0 (compatible; MSIE 6.0; AOL 7.0; Windows NT 5.0).

    2. Some version of MS IE use exceptional version number strings, for example MSIE+5.5+. If version numbers have been test exceptional version number strings might remain unnoticed.

    3. MS IE for Mac and MS IE for Windows have not taken account separately. That can be done by adding conditions (navigator.userAgent.indexOf('Mac')!=-1) and (navigator.userAgent.indexOf('Win')!=-1). Don't use full names of platforms because some browser use for example identification strings Win32 and Mac_PPC.

    4. Opera browsers have many identification modes and they in most cases they partially "lie". In most case Opera works in the mode Identify as MSIE 5.0. Opera might get bad CSS or it doesn't get any CSS in solution, where has only been asked browser names and version numbers depending of course the way how browsers have been detected. The ways how I have detected in my examples Netscape 4.x and Netscape 6.x+ browsers don't concern Opera even it would be in a mode, where it pretends to be some Netscape browser. If detections are nested they might slower the performance.

    5. It is not possible to get the real version number of Opera by using for example navigator.appVersion.indexOf('5.')>=0 because Opera return just the version of the browser, which it pretends to be.

    6. Even if Opera would be in any identification mode, at least relative new versions can however always be identified as Opera, but this detection must be before other browser-specific detections or there must be additional conditions so that Opera would not read the incorrect CSS.

    7. I found that Opera 4.x is very sensitive that before spaces is a backslash (\) and after it just one space and no additional line breaks. Because of small error first detections, which I made failed. If line breaks makes the code clearer, the code must be catenated for example at the following way:

      document.writeln('\<lin'+
         'k\ rel=\"stylesheet\"\ type=\"text\/css\"\'+
         'href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+
         sStyleMedia+'\"\ \/\>');

    8. According to an e-email for Opera 3.x browsers is impossible reliable to give CSS, which is intended for browsers, which don't support DOM or proprietary DHTML because they don't always give the version number of the browser itself. I don't know, if this is true. At least Opera 3.62 for EPOC informs the version number.

    9. Concering mobile phones Symbian OS browsers use in their identification string as the platform the string EPOC. As far as I know Opera 5.x+ are the only browsers which support dynamic menus.


      Opera for Symbian: General Opera information.
    10. In the second, third and fourth alternatives Opera 4.x-5.x browsers might suffer. They don't read the JavaScript if the user has used backward/forward arrows (or other corresponding actions) of the browsers. If the visitor doesn't always select a new page they render links at the way, how other new browsers render links if the JavaScript support has been turned off. This disadvantage concerns however only few visitors.

    11. If Mozilla Gecko browsers are necessary to detect more exactly I recommend to use additional detections, which base on the Build ID of the browsers. They can be combined with the detections, which I have used in my examples. For example (Gecko && (parseInt(navigator.productSub)>=20011018)) concerns Netscape 6.1/ Mozilla 0.9.1 and newer browsers. You can separate Netcape from Mozilla by adding for example the condition condition navigator.vendor == ('Netscape7'). Then you can give different dates for Netscape browsers if it is necessary. In principle separations could also be done by using as exact version numbers as possible, for example userAgent.indexOf('Netscape6\/6.1'). I have a list of dates and some detection examples in the extra page, which concerns Netscape[S].

    12. You can use as a model a commented source code fragment[S], which I have used. You can also find more detection examples from pages of an e-mail friend of mine.


    13. In the Linux platform can be used also the Konqueror browser. As default it writes the name and the version number of the browsers and it uses an own rendering engine. Then it can be detected with it own name but an additional condition must be used (in the examples, which I have used it would be && !Gecko) because Konqueror can be set to use the Mozilla Gecko rendering engine. The user of the browser can however alter the identification string, when it is impossible to detect reliable Konqueror.

    14. When the purpose is to design forward-compatible detections it could be reasonable to eliminate effects of possible changes in the case of the sub-strings. Adding either toLowerCase(). or toUpperCase(). before indexOf changes in the case have no effects (for example toLowerCase().indexOf('win') works with both Windows and WINDOWS strings).

    15. I handle in another pages PHP-based[S] browser detections.

  3. All links are in the page, but elements, which define layers have been generated by scripts, when all links are visible, if the JavaScript support has been turner off. Below is an example of a generated start-tags (they needs also corresponding generated end-tag):

    <script language="JavaScript" type="text/javascript">
    <!--
    if (document.layers)
    {document.writeln('\<lay'+'er\ id=\"Layer1\"\ class="\pageGroup\"\... \>');}

    else {document.writeln('\<di'+'v\ id=\"Layer1\"\ class="\pageGroup\"\... \>');}

    //-->
    </script>
  4. It is possible to make a combination of two previous alternatives. In this solution in the main CSS-file is almost all needed CSS including most of the layer-related CSS. Only very little is in the CSS-file especially for dynamic menus. Even if the browser doesn't read the CSS file for dynamic menus, dynamic menus could work at least partial if just the browser can generate the necessary elements.

  5. In the menu is in a clear place a link to a special link page, which has continuation links into all necessary pages. It is not necessary that the actual menu is as default visible. There can be instead of the menu a link to the special link page, which can be for example a big link table.

  6. In situations, where JavaScript support has been turned off, the browser gets an alternative link set. The basic CSS-file ends in situation, where dynamic menus will be hided and the browser reveals alternative links. Below is an example of this solution:

    /* The following CSS is in the end of the basicScreen.css file: */
    #alternativeLinkSet {display:block;} /* Links for the alternative navigation. */
    #tableAllPages {display:none} /* Links for dynamic menus. */


    /* The following CSS is the beginning of the layers.css: */
    #tableAllPages {display:block}
    #alternativeLinkSet {display:none}

    Browser-specific notes:

    1. If the CSS commands to changes property values and much CSS has been given in two big CSS-files, the situation however "stress" browsers. I found in a test, where browsers had alternative link set in situations, where the JavaScript has been turned off in MS IE 5.0 for Windows the page must reload to get dynamic menus. This might be related on CSS (and/or servers), but not necessary because the CSS was partially depend with JavaScript supports. One way might be to generate CSS for hiding the alternative link set/ link set of revealing dynamic menus CSS with JavaScript like in the example below, but the following system doesn't necessary solve the problem:

      <script language="JavaScript" type="text/javascript">
      <!--
      {document.writeln('\<sty'+'le\ type=\"text\/css\"\>');
      document.writeln('\<'+'!--');
      document.writeln('#alternativeLinkSet\{display:none\}');
      document.writeln('#tableAllPages\{display:block\}');
      document.writeln('--'+'\>');
      document.writeln('\<\/sty'+'le\>');}

      //-->
      </script>
    2. That previous solution doesn't solve another problem, which concerns alternative links. The another weakness of alternative links is that if the JavaScript support have been disabled Netscape 4.x shows both links for the dynamic menus and alternative links because taking off the JavaScript support takes off also the CSS-support. Also such browsers, which don't support at all CSS get two link sets.

In all ways to give different CSS for situations, where JavaScript support is enabled/ disabled have some problems, which might be related on servers, JavaScript handling or CSS-handing. If the server must gather CSS from several pieces, the browser might not get it enough fast, the browser might render the page incorrectly. If connections work well, CSS doesn't cause problems.

[Top]