Multi-function Menu Question

[Mark Preston]

Its perhaps a bit early to ask, since I'm still doing the page design
and haven't got down to the coding yet, but I wonder if anyone can help
with a bit of a question. To lay the groundwork, a quick description of
the template design for the pages:-

1. There will be a body section of the page consisting of a set of <div>
layers. The top level layers will all have the same CSS class to ensure
a common design look.

2. At the side or top of the page (not yet decided) there will be a
small number of navigation text phrases. These will be set up as
<a>ddress tags to that they can have events attached.

3. The events on the navigation menu will be "onClick" events and will
switch the layer they refer to to be visible (and the others to be
invisible, obviously).

4. The reference on the address tags should, I know, be of the form
"href='javascript:;'" to prevent page reloads when clicking on the menu
option since I have an "onLoad" event to set up the basic page. No
problem here - I've made pages like this loads of times.

5. Now comes the fun bit... I want the pages to be fully accessible to
anyone at all (which is why the menu is text rather than images in the
first place). That has to include people who do not have
JavaScript-enabled browsers.

So - I will start loading the page with all the <div> layers visible
(the onLoad event will switch off those not initially in use). These
will switch in and out of visibility for browsers using JavaScript. For
those who don't use JavaScript, the page will display with all layers
visible, of course, and for these users the menu options should go to
anchor points at the top of each top-level layer section.

Now - the question is, how can I use anchor points (of the form
"href='#anchorname'" and yet still prevent page-reloads when the menu
option is selected? I know that some browsers will not do page reloads
anyway, but I need to be sure that none will. Any ideas?

 

[Richard Cornford]

Mark Preston wrote:

4. The reference on the address tags should, I know, be of the form
"href='javascript:;'" to prevent page reloads when clicking on the
menu option since I have an "onLoad" event to set up the basic page.
No problem here - I've made pages like this loads of times.

Absolute rubbish. This group strongly and repeatedly discourages the use
of javascript pseudo protocol HREFs, partly because they offer no
facility for clean degradation (or meaningful actions without javascript
being enabled) and partly because they directly cause problems with some
browser and OS combinations:-

<URL: http://jibbering.com/faq/#FAQ4_24 >

And that particular formulation of a javascript pseudo protocol HREF -
"javascript:;" - can be demonstrated to directly produce internally
suppressed syntax errors on IE 4 & 5 (it probably produces them on later
versions but the facility for the demonstration was removed).
"javascript: void 0;" would be better as it will not represent a syntax
error (but preferably don't use javascript HREFs at all, ever).

5. Now comes the fun bit... I want the pages to be fully accessible to
anyone at all (which is why the menu is text rather than images in the
first place). That has to include people who do not have
JavaScript-enabled browsers.

You might consider that to be fully accessible it would be necessary to
facilitate keyboard navigation, and apparently not all javascript
capable/enabled browsers trigger onclick events when a currently focused
link is triggered via the keyboard (at least some older ones don't).
Doubling-up with a keydown/press event might be advisable (with
appropriate handling for the browsers that will trigger onclick in
addition to key events).

Now - the question is, how can I use anchor points (of the form
"href='#anchorname'" and yet still prevent page-reloads when the
menu option is selected? I know that some browsers will not do
page reloads anyway, but I need to be sure that none will. Any
ideas?

Placing a fragment identifier in the HREF is the most sensible thing to
do. It does not need to conflict with the javascript in the onclick
handler because the onclick handler is allowed to prevent the navigation
using the HREF by cancelling the click event, usually be returning false
from the handler (possibly with additional W3C DOM and IE specific
default action cancelling code).

See:-

<URL: http://www.litotes.demon.co.uk/js_info/pop_ups.html >

- for an example resembling what you are describing (note: the first
link will re-load the page with the script disabled and so can be used
to simulate interaction without javascript).

Richard.

 

[Mark Preston]

Mark Preston wrote:

4. The reference on the address tags should, I know, be of the form
"href='javascript:;'" [snip]

Absolute rubbish. This group strongly and repeatedly discourages the use
of javascript pseudo protocol HREFs, partly because they offer no
facility for clean degradation (or meaningful actions without javascript
being enabled) and partly because they directly cause problems with some
browser and OS combinations:-

I do know that... if you read on, you will see that the entire point of
the question is all *about* "clean degredation" rather than Javascript
HREFs. It just happens that - as I said - in the past I have used them a
lot (because they happen to be pretty much "built-in" to DreamWeaver MX)
and would prefer *not* to any more.

And that particular formulation of a javascript pseudo protocol HREF -
"javascript:;" - can be demonstrated to directly produce internally
suppressed syntax errors on IE 4 & 5 (it probably produces them on later
versions but the facility for the demonstration was removed).
"javascript: void 0;" would be better as it will not represent a syntax
error (but preferably don't use javascript HREFs at all, ever).

This is actually what I initially replaced my "javascript:;" references
with when the glitch in IE became clear. But it isn't good enough for
non-enabled browsers, which is why I want to go further... hence my
question in the first place.

You might consider that to be fully accessible it would be necessary to
facilitate keyboard navigation, and apparently not all javascript
capable/enabled browsers trigger onclick events when a currently focused
link is triggered via the keyboard (at least some older ones don't).
Doubling-up with a keydown/press event might be advisable (with
appropriate handling for the browsers that will trigger onclick in
addition to key events).

This is the sort of thing I've been looking for as an answer! I will
look into keyboard triggers and vocal triggers (vocal is likely to be
the most important, but either could apply). Thanks.

Placing a fragment identifier in the HREF is the most sensible thing to
do. It does not need to conflict with the javascript in the onclick
handler because the onclick handler is allowed to prevent the navigation
using the HREF by cancelling the click event, usually be returning false
from the handler (possibly with additional W3C DOM and IE specific
default action cancelling code).

See:-

<URL: http://www.litotes.demon.co.uk/js_info/pop_ups.html >

- for an example resembling what you are describing (note: the first
link will re-load the page with the script disabled and so can be used
to simulate interaction without javascript).

Got it! That is EXACTLY the sort of link I was looking for. I've also
found out that the Mozilla core engine since version 0.7 has been
updated to stop a glitch it had that caused page reloads with some fixed
anchors, so that solves that one as well. Unfortunately, it does still
seem to do page reloads at fairly unpredictable times if you mess around
with keyup/keydown events. There's still a little trouble with Lynx, but
that should sort out this week.

Thanks for the ideas and link.