Updated for W3C'ish DOMs and including horizontal, vertical and tertiary menus in both directions. If your browser is W3C compliant (Gecko only in mid 2003) the pop-ups. pop-downs do not use javascript at all - they have been implemented with pure CSS. Not a line of code in sight.
We decided to do a site makeover in '2000 for all kinds of reasons. We reviewed all the possible alternative and snazzy technologies we had seen and the only that that consistently ranked high on everyones lists of 'useful' (as opposed to 'snazzy') was pop-out (or pop-down) menus. These pesky creatures, the consensus was, speeded up in-site navigation and had the additional benefit that you could check early on if you were going down the right path.
We had to have pop-out menus on the new site.
You can skip the rest of this soul-searching explanation and get to the tech meat here.
Apache Configuration and Browser detection
Cross Browser DHTML, CSS and Javascript (Jscript)
We looked at the available choices (free stuff naturally) and they are great, maybe even fantastic (see our links pages). But on closer examination we decided not to use them for the following reasons:
The smallest one we could find was 27K (up to 35K) OK so that includes comments that could be stripped out ... but folks have got to download this stuff and servers have got to spew it out. Our budget was 3K'ish max.
We figured we would need to customise and enhance them (.. fix bugs) at some point and due to size and the fact they 'push the envelop' that was going to be a job in and of itself.
A quick look at the code indicated that over 50% of it was only used 50% of the time because of 'cross browser' incompatibilities. Welcome to the gruesome world of cross browser DHTML, CSS and Javascript.
We own the Server Side as well (aha! you may say). We had access to all the features of an Apache based (is there any other?) web server.
Our pop-out menus, like we suspect most folks, are static in nature not dynamic. Most of the off-the-shelf solutions focus on dynamic menus (a side effect of the cross-browser code strategies adopted).
It was pretty obvious, pretty early (like the second day) that we were stuck with supporting each browser family differently...so having accepted that...and wanting lightweight menus (OK so we are mean) ..and working on the theory that we could quickly learn enough about CSS, DHTML, Javascript, DOMs and SSI (how naive are these guys) we decided on the following technical strategy:
Apache Server Side Includes (SSIs) to serve up browser specific pages. Yes we could have used PHP but for the functionality we needed the SSI documentation was thinner and No we did not have to rename every file with an .shtml suffix.
Browser specific CSS style sheets (can anyone read a Netscape/Mozilla 7pt font).
Browser specific HTML specifically the <LAYER> tag (yes you can use DIV and SPAN but there are quirks - we use both LAYER and SPAN for NS4.x).
Browser specific Javascript to manipulate the Document Object Models (DOM) and other variables.
So sometime later a much chastened couple of guys knew a lot more about a number of technologies ...
To summarise the experience:
Our system is small and fast (approx. 2K per page not 27K).
We know a lot about CSS, DHTML, DOMs and their Javascript manipulation (which will pay dividends later.. we hope (ed: it didn't!).
Our acquired knowledge means we can better evaluate technical web decisions.
We proved that 'lightweight' pop-outs are possible and practical. Even in a 'bandwidth fat' world IOHO that matters.
However, if you must use an off-the-shelf solution, don't care about the overhead, or have no control over the server side then have no fears about the quality of the available choices. They are very good and getting better.
Are there down-sides or limitations in our approach?
We need to keep up to date with browser based technology and the latest browser versions (this is also true for an 'off-the-shelf' solution but someone else does all the hard work). This is becoming a lower overhead with the W3C'ish DOM 5+ browsers.
We are paying an overhead in the server (offset by substantially reduced data volumes)
Time cost. We had to learn everything we needed and where to find it. Hence these pages.
We don't support all browsers - couldn't be bothered to handle all those stupid quirks. We support MSIE (we have a choice?) and any Gecko based browser (which is where we hope the future action will be) but decreasing rapidly our support for NS4.x and Opera not at all - why replace one quirky browser (NS4.x) with another (Opera - as of Opera 7.x this is no longer true it's now a pretty good and very compliant browser).
So in the spirit that "opening the kimono is good for the soul" (eh!) this is what we did ...and learned...mostly painfully.
[an error occurred while processing this directive]