Menu Systems for Website Navigation

Introduction

Since the beginnings of the Internet in this country, I have been designing web pages, starting on Netscape 2.  My first Studio Connections website used preloaded image swapping techniques to animate menu buttons and load images into areas on the page, using no more than HTML and JavaScript.  Netscape included a simple, scriptable MIDI player plugin.  All of this worked well and efficiently with Netscape 4 and was backward compatible with Netscape 3 and 2.  At the time, IE3 was so bad that it was not even a consideration!

Then came the browser wars.  When IE4 arrived, I found to my horror that my website performed poorly on it and my music player didn't work!  The emergence of new and conflicting "standards" turned website design into a nightmare.  One huge problem was the method of addressing components on the web page - the so-called Document Object Model (DOM) which varied greatly with different browsers.

And so began the horrible era where designers had to create up to three different versions of their JavaScript code - one for Netscape 4, one for IE4 and one for "Level 5" browsers - plus go to the trouble of detecting the visitor's browser (which in itself turned into a nightmare), if they wanted to utilise so-called "dynamic HTML".

On top of this, CSS implementations in early browsers were inconsistent and often quirky, making the use of CSS virtually out of the question in the early days.  The only safe option was to settle for raw HTML formatting, which wasn't as bad as it sounds if you used a decent text editor.  Even then there were inconsistencies in HTML implementation with different browsers.  For example, IE interpreted some font size attributes differently.

There were minimal positional options with raw HTML.  Designers quickly discovered that the best way to achieve layout was to use tables, with multiple cells of the appropriate size with no borders.  This was a purpose that HTML tables were never designed for.  However, to this day it remains the most reliable method of achieving layout.  Even MySpace used this technique for layout.  I apologise to the standards guys for saying this!

The situation improved slightly with the demise of browsers like Netscape 4, IE4 and all versions of IE for Mac.  The W3c organisation attempted to define a set of standards, and it became possible to draw the line at "Level 5" browsers or higher.  But even CSS-2 was not fully supported by IE until IE8.  Even worse, IE interprets some things differently by default, such when specifying the width of a box.  IE offers some powerful proprietory features, but it is pointless using them if they are not supported by other browsers.  The Internet is full of "workarounds" to address problems with specific browsers, but these are often dangerous to other (and possibly future) browsers.

IE6 was with us for quite a few years and I learned to live with its idiosyncracies.  A clean XP install with IE6 only seemed to outperform alternative browsers like FireFox, with their associated Java overhead.  I strived to make "standards compliant" documents, used the !DOCTYPE declaration and checked them on the W3c Validator.  I simply tried to dodge any problems with IE5, IE5.5 or IE6 by staying away from known inconsistencies and unsupported commands.  Where necessary, I used "safe" workarounds such as giving a box content, staying within the boundaries of the standards.  Most of my current code was developed during this period.  Then along came IE7 and IE8 - both with different behaviour.  Now I'm expected to add <meta http-equiv="X-UA-Compatible" content="IE=8" /> to all my pages!

The original concept of HTML was that it was supposed to be fully backward compatible.  The idea was that when a new feature was added to HTML, an older browser simply ignored the unrecognised tag, without error.  Then we had to change to XHTML for some reason which I still don't understand.

The problem is that most older website designs with any kind of creative dynamic HTML on them will most likely have problems when viewed on a modern browser and older browsers will usually have big trouble or even crash when viewing a modern web page.  Whatever happened to the backward compatability concept?  Surely this is contrary to the philosophy of the Internet and has made archiving a nightmare.

With all of this chaos, the evolution of web design has been stifled and many designers resort to plugins such as Flash Player to perform many tasks that HTML, CSS and JavaScript should be able to do easily.  Microsoft introduced a "security update" to screw up the Flash Player plugin too, by putting an ugly box around it and making you click on it twice to use it.  (Yeah, yeah, I know about the workaround...)

In the past, I seem to have spent more time stuffing around re-writing code to keep up with the ongoing changes than actually putting content into my website!  I spent a lot of time developing a JavaScript controlled multi-track player using a hidden embedded player with a custom interface.  Over time, it interfaced to specific plugins such as Windows Media Player and Apple QuickTime.  Naturally, these required different specific code for each player.  Although I was proud of my achievement, I had ongoing problems with new versions of players and browsers such as IE for Mac.  I always had trouble with new versions of the QuickTime plugin and getting it to work reliably at all was a challenge.  I spat the dummy somewhere around the time one of the IE updates started to question a web page trying to use its own built-in Windows Media Player plugin...

The reality is that designers must still restrict themselves to a subset of features that can be used safely on most modern browsers.  Designers must assume nothing, adding tests where possible to check whether a specific feature is supported before attempting to use it and devising ways for a design to "degrade gracefully" when that feature in unavailable.  In addition, websites should be at least viewable on older browsers - something which is often overlooked these days.  Even if a web designer does manage to overcome all of the existing hurdles, I have come to the sad conclusion that there can be no guarantee that a web page will necessarilly work on future browsers.  To be honest, I'm over it!

Menu systems are often marred by unexplainable delays, error messages and random dotted outlines that destroy their appearance.  Due to the ongoing problems with different browsers, website designers have become less inclined to risk anything more than basic menu designs.  Creating more sophisticated looking menu systems still remains a challenge to web designers.  Many current websites still have problems with ugly outlines appearing when a button is clicked.

In this article, we'll start by looking at some raw HTML links, then try using CSS to control their appearance and behaviour.  We will then add JavaScript functions, slowly building an intellegent framework that supports a wide variety of menu system designs - as simple or complex as you want.

The menu buttons are carefully constructed to be capable of animation with a sophisticated look and feel.  They can be based around standard text-based links using no more than CSS to create buttons.  Alternatively they can use foreground and multiple background graphic images to construct more elaborate buttons, limited only by the designer's imagination.

 

- Colin Abrahams


Contents

  1. Basic HTML links
  2. Controlling links with CSS
  3. Controlling links with JavaScript
  4. Fixing a few problems
  5. Bringing our buttons to life
  6. Using graphics for buttons
  7. Loosing the outline
  8. Fixed width buttons
  9. Irregularly shaped buttons