Hiermenus Go Forth, X - DHTML Lab | 3
Hiermenus Go Forth, X:
Version 4.0.3 - The Complete Script (Full-Window)
Promises To Keep
In our first Version 4 column, we promised:
HM Version 4 is comprised of several external files, each one optimized for a particular browser. Only the optimized file is loaded, giving users only the code necessary for their browser.
The original feedback was negative. Most authors believed that this approach would lead to a "maintenance nightmare." We therefore reneged on our promise and produced a one-size-fits-all script. Well, the feedback became even more negative. Our original instincts seem to have been correct: The single script is more nightmarish than the separate ones. With Version 4.0.3, we move to browser-specific scripts.
hierMenus.js R.I.P.
Our external scripts need different names, of course, so we finally lay hierMenus.js to rest. The new external scripts identify the browser and follow our Version 4 naming scheme:
- HM_ScriptNS4.js - used by Netscape Navigator 4.x for all platforms
- HM_ScriptIE4.js - used by Internet Explorer 4.x for Windows
- HM_ScriptDOM.js - used by Internet Explorer 5.x and Gecko-based browsers for all platforms
hierArrays.js R.I.P.
It follows that the external array file should also be renamed to follow the Version 4 naming scheme, so it is now called HM_Arrays.js.
onload
In the interest of menu-creation speed, Versions 4.0 --> 4.0.2 created the menu elements during page load. Creation speed was truly improved and the page's onload event handler was freed up for use by other scripts.
However, problems arose for nearly all browsers:
- NS4
Reloading of the page using Shift-Reload could freeze NS4 (?). Seems the dynamic insertion of nested <LAYER> tags, although proper NS HTML, generated confusion. So we revert back to using the powerful and stable new Layer() constructor which is only available after page load. IE for Windows
Poor non-HM-related page HTML could lead to errors. See our discussion in Column 45. By creating the menus after page load, we give IE time to resolve page HTML problems, and allow authors to make the odd "mistake."IE5 for Macintosh
Complex menu trees could display in a manner that did not reflect their properties. The HTML generated would be proper and clean, but the screen display did not reflect it. Again, internal confusion during code generation seems to have been the cause.NS6
The screen display would not be refreshed properly, leading to "cut off" elements. Of all the browser problems this was the least serious, as a window minimize-restore would always solve it.
Therefore, check for conflicting onload handlers in other scripts or your page's BODY tag when using Version 4.0.3.
More notes on the next page.
Produced by Peter Belesis and
All Rights Reserved. Legal Notices.Created: Jan 23, 2001
Revised: Jan 23, 2001
URL: https://www.webreference.com/dhtml/column46/2.html