View Full Version : HV Menu...

02-01-2005, 11:17 PM
Everyone says that javascript menus are evil because they block out a lot of your users, right? Well, I'm using a js menu right now, until I can figure out this CSS thing. So my solution is to figure out a way to check for javascript first and then, if javascript is not enabled, to come up with a message (alert box or something) that explains how to turn it on and why. Anyone have any idea how to do this? Or if it is possible?

02-02-2005, 01:07 AM
Everyone says that javascript menus are evil because they block out a lot of your users, right?With typical implementations, yes. They also block what some might consider the most important of visitors: search engine robots. The other problem with interactive menus is that they can contain too much information: a menu shouldn't me a site map.

Notice that I said "typical implementations". A menu doesn't have to be evil and inaccessible, it just so happens that the vast majority are, including those at Dynamic Drive (among other script collection sites). It is entirely possible to produce one which provides sensible navigation no matter what user agent is used (I should get back to mine :)), but not many exist in the wild.

[M]y solution is to figure out a way to check for javascript firstThe problem with scripting user agents isn't limited to whether client-side scripts can be enabled or not, but what is supported when such features are enabled.

A well-written script will probe its host to determine what's available. This should be done on a one-to-one basis. That is, test for each method or property needed. Unfortunately, many scripts either fail to do this at all, or make rather unfounded assumptions. For example,

var has_dom = !!document.getElementById;would be nonsense. Just because a host happens to have a getElementById property on the document object doesn't mean that it supports the entire W3C DOM. Whilst such assumptions have some truth in the most common cases, it is not universal.

[...] if javascript is not enabled, to come up with a message (alert box or something) that explains how to turn it on and why.What if they have no control over the settings (can easily be the case in the workplace or public library)? What if their user agent simply isn't capable (using an old browser or a portable device)? What if they just don't want to (it is their machine, after all)? The point is, you can't control the environment and you don't have the right to tell visitors how to browse. If you start doing that, you'll lose your audience. It's as simple as that.

From my perspective, you have three choices:

Use an inaccessible menu and face the consequences.
Use one of those rare, accessible menus.
Abandon the idea and go for a more conventional navigation approach.
As far as (2) is concerned, the only such menus I can point to at the moment are from the now defunct DevEdge (http://web.archive.org/web/20030602213921/devedge.netscape.com/viewsource/2003/devedge-redesign-js/) website. I have some misgivings over the systems shown there (notice the links to other sites) as they use some browser detection which is a Bad Thing, but they're about the best I'm aware of for the moment.


02-02-2005, 09:50 PM
(I should get back to mine :)),

Maybe you'd like to help me out? :)

Well, like I said, a javascript menu is definitely not my first choice. Right now I'm in the middle of creating a CSS based drop down menu, but it's proving more difficult than I at first had hoped, and in the meantime I need something to get people where they need to go. So as far as accesible menus goes...explain in simple(r) terms what I should be looking for in a script?

02-03-2005, 06:24 PM
So as far as accesible menus goes...explain in simple(r) terms what I should be looking for in a script?The principle is really very simple: the menu content should be based soley on mark-up. The generally accepted approach is to create a nested list of links where each menu item maps directly to a list item. If the script cannot execute - because scripting support is disabled or insufficient to construct the menu - the list is rendered according to whatever style information might apply to it. If you find something which operates on these lines, you can be confident that you're using a system that goes at least some way to being accessible. Other obvious tests that you can perform are disabling client-side scripting and CSS. If the menu is still usable, there's another plus.

Of all of the scripts here, I think only the switch menu doesn't build a menu entirely from script. However, the author chose a very bad system of div and span elements which is structural nonsense.

The final point I'd like to make is not so much what makes a menu accessible, but how to use them in an accessible way. I touched on it briefly: menus shouldn't become site maps. Menus that are too deep are difficult to use for anyone, whether it's a disabled or an able-bodied visitor. One suggestion I read recently was that only the current section should have a detailed list of sub-sections. Others top-level items should either be left as-is (that is, no sub-sections are listed) or as brief as possible.

Despite the simple principle, it's not so easy to implement. What stopped my development cold was IE. I intended to produce a very flexible system that allowed CSS to customise the entire menu in a very intuitive manner. However, rendering errors in IE (and early, now obsolete, Mozilla versions) mean that the list needs to be pulled apart, making the original idea impossible. I now have to actually worry about what level of control authors would like and set about providing it whereas before I could ignore that aspect.


02-03-2005, 09:08 PM
Alright, thanks for all your help. The seach goes on...

02-06-2005, 05:16 PM
Hi there,

found your posts interesting as a designer and web/cd/dvd creator myself. I agree with mwinter that professionally you are dead in the water if you start dictating terms with end users. You are best keeping things as simple as possible because most domestic users and certainly professionals/execs/education will not (know how to) change any settings even if they have the authority.

In design we talk about form and function - form means you do things for creative and aesthetic reasons to draw attention or make a point to the viewer - like a painting. Function means you design for a purpose and the design should fit the purpose as simply and effectively as possible. Websites should be 90% function and 10% form - that's hard for an artistic person like me to say but its reality if you want to be considered a good website designer. A lot of java/script is employed for the wrong reasons - to be showy.

Personally I feel that the extended menu stuff should be kept to folio pieces or where you are trying to impress someone as to your ability. Kiosks and exhibition applications are also viable because you can control the hardware and software environment (I also build kiosks and in this case you can set the browser up however you like). But again, as stated by mwinter, this should only be done if it absolutely helps the site and navigation - doing it 'just because you can' is a mistake.

There are detectors you could employ for javascript on/off detection but don't consider it. I have a personal friend who is an exec in a bank and she says if she even sees "best viewed with...." or a similar warning message on a front page she closes the site down and goes elsewhere. Sale lost! This is a very commen scenario today.

From one developer to another, under Windows, its a complete nightmare now because every one is so wary of problems running their PC's. The biggest single issue this year for the Wintel world will be browser hi-jacking by aggressive advertisers and spammers, and one of the ways this is achieved is through 3rd party installs of 'helpful' software plug-ins and support apps (the malicious stuff is often hidden in the install so you have no idea what is being run until its too late). Many people are having browser protection installed and guess what it interferes with in most cases - java and javascript. And on top of this, techs in organsiations now absolutely forbid any changes to web browsing by staff for security reasons. Everyone is so wary now that they will leave best alone and will ignore your requests to activate this and that.

What might happen in future is a kind of locked 'standard' like we have in DVD construction, which all browsers will operate under. I've read that the military are developing something like this with Apple. I'm not one for Big Brother type implementations but at least then we would know where we stand. Someone needs to do something about the mish mash which is online development, web browsing and email right now.


02-07-2005, 06:02 PM
Thanks for your replies everyone. I guess I really shouldn't use a detector. But, Maverik, I don't agree with you about one thing. I think that "the extended menu stuff" is great for navigation. Especially if your site is big. Which, the site I'm working on now isn't exactly gigantic in size, but I definitely think I need an extended menu for it. So I'm working on a CSS menu as we speak, but I'm trying to figure out the links for it....

02-09-2005, 03:43 PM
Your welcome

we all have to start somewhere and rules are made to be broken. Thats how we all move forward in this world so go for it with the extended menu's - if it works for you have a ball!