Hier menu in frameset

[MP Multimedia]

Hello everyone, I need help.

I'm using a hierarchical menu made in javascript.

When I used it in a one frame page, it came out fine. But now I need to change my page to 3 frames: a top frame, a left frame and a right frame.

The menu is on the top frame and when hovering the categories, the sections appear under the left and right frame.

How do I solve that problem? (I use Dreamweaver.) Thanks for all your answers.

_______________ ____

Marie-Perle
www.mpmultimedia.ca

[Jim Ley]

On Fri, 11 Jul 2003 17:57:32 +0100, "Richard Cornford"
<Ri*****@litote s.demon.co.uk> wrote:

I have often wondered how an aural browser would implement the dynamic
DOM level 2 interfaces (createElement, appendChild, and so on). What
should it do if a text node was inserted? Suddenly blurt out the text,
start reading the document again from the beginning or ignore the
insertion?
I think it should ignore the insertion unless it happens to be reading
that element, consider a form where you insert text to indicate that a
field might have been incorrectly filled out an ("are you really 70ft
tall?" say) will allow the user if reviewing the form to hear the
indication.

I generally believe though that there's no reason to generate content
with script, just to move it around, the above style of messages (what
misguided people generally use alert for) is the generally the only
time it's appropriate.
My strategy is to have an external CSS provide most of
the styling for the ULs but to use JavaScript in the HEAD of the page to
write out a STYLE section that introduces the critical CSS. Obviously in
the absence of JavaScript the ULs retain their externally specified (or
default) display characteristics so clean degradation is achieved.

Risky, since you're rendering the content invisible with CSS, before
you've checked you've got the ability to render it visible again with
javascript.

Have you seen my (now very old) approach?
http://jibbering.com/accessibility/

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Richard Cornford]

"Jim Ley" <ji*@jibbering. com> wrote in message
news:3f******** ********@news.c is.dfn.de...

I have often wondered how an aural browser would implement
the dynamic DOM level 2 interfaces (createElement, appendChild,
and so on). What should it do if a text node was inserted?
Suddenly blurt out the text, start reading the document
again from the beginning or ignore the insertion?
I think it should ignore the insertion unless it happens to
be reading that element, consider a form where you insert text
to indicate that a field might have been incorrectly filled
out an ("are you really 70ft tall?" say) will allow the user
if reviewing the form to hear the indication.

It occurred to me that the aural browser could announce the change in
the document ("a script has modified the document" or something). It
would have to know that the inserted node would modify the text but
might be able to offer the user the opportunity to re-read just the
containing element or one of its ancestors to provide context without
having to start afresh from the beginning. That would only sensibly
apply if the affected elements had already bean read, and interrupting
its current output mid-paragraph would not be a good idea.

In the event of a form submission being aborted by a validation script
the user is still going to have to be told that it has happened in order
to know to go and review the form. Clearly implementing JavaScript in
aural browsers is something that needs a lot of thought (and input from
the people on the receiving end. If clean degradation was common
practice (rather than just recommended) they might decide it wasn't
worth the bother).
I generally believe though that there's no reason to generate
content with script, just to move it around, the above style
of messages (what misguided people generally use alert for)
is the generally the only time it's appropriate.
To stand a chance at cleanly degrading the content must be in the HTML
and not the JavaScript. That became self evident as soon as I took on
board the need to consider every aspect of a script including its total
failure. I deeply regret all of the scripts that I wrote before I knew
any better, If I had known then ... [etc] I would have been able to do a
good job of them instead of just doing what I was asked to do. Still,
the only way to avoid the regret would be to never learn anything new,
and at least I now don't have to repeat my past mistakes (just spot my
new ones :).

My strategy is to have an external CSS provide most of
the styling for the ULs but to use JavaScript in the HEAD
of the page to write out a STYLE section that introduces the
critical CSS. Obviously in the absence of JavaScript the ULs
retain their externally specified (or default) display
characteristi cs so clean degradation is achieved.

Risky, since you're rendering the content invisible with CSS,
before you've checked you've got the ability to render it
visible again with javascript.

I realise that it is risky and needs very cautions handling. I never did
intend to write out display:none; or visibility:hidd en; at that point
(really a job for onload). Mainly I was thinking of position:absolu te;
as there are browsers that do not facilitate setting that onload and
less dynamic browsers like Opera <= 6 won't re-flow the rest of he
contents if you switch the position properties. However:-
Have you seen my (now very old) approach?
http://jibbering.com/accessibility/

I had looked at your menu script before but that was a timely reminder
because I was just not thinking of putting the menu HTML in any other
place but the top of the page. But if I follow your example and pace the
menu HTML after the contents it will not be important if the rest of the
content does not re-low when the position = 'absolute' settings are
made, as a bit of blank space at the foot of the page on a few browsers
is not a high price to pay in exchange for the extra safety. That leaves
the only reason for writing out a STYLE tag as an attempt to support
dinosaur browsers like Netscape 4 and I wasn't convinced that was worth
all of the extra code and branching if the page can be navigable under
any circumstances.

I also really like the link to the same page with a query string to give
the user the option of disabling the menu themselves. That is such a
good idea that it would be stupid not to use it. It might also prove the
only answer to the point that David raised about screen readers working
with IE.

Richard.

[Richard Cornford]

"Jim Ley" <ji*@jibbering. com> wrote in message
news:3f******** ******@news.cis .dfn.de...

In the event of a form submission being
aborted by a validation script ...

aborting submissions are also risky... best bet is to validate as you
go along, but still allow submission in all cases, you may miss out
more people on some client-side validation, but it's better than alert
or similar, or not letting users know you've blocked the submission.

I have tended to be resistant to the idea a validating as your go along
but that is mostly because it seems to be accompanied by re-focusing the
invalid field (and of course lots of noisy alerts). I can however see
how this could work. The user entering an invalid height is allowed to
move on but a note saying, "Are your really this tall?" on less dynamic
browsers and "Are you really 70 feet tall?" on the more flexible ones,
is revealed adjacent to the field. The user either notices and corrects
or they submit the form and it is rejected by the server, and returned
with the pertinent notes pre-shown.

It might also prove the only answer to the point that David raised
about screen readers working with IE.

That script was tested with (a now old) Jaws for windows + IE config,
and seemed to work in some of the modes of Jaws, but it wasn't as
clear as the no navigation version.

I am going to have to do some experimentation for myself, unfortunately
I won't have an opportunity for a couple of weeks. I am going to follow
your example and provide the script disabling link, its too easy to
implement and too clearly valuable not to include one.

Richard.