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

[David Dorward]

MP Multimedia wrote:

I'm using a hierarchical menu made in javascript.
Uh oh. That's very difficult to do right (some would say its impossible)
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.
You _need_ to change to frames? Why are you moving backwards? Even the
inventor of frames (Netscape) removed them from their homepage after 6
months becuase they realised how much they sucked.

http://stone.thecoreworlds.net/www/frames/
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?

Create identical content in the other frames and line them up very very
carefully.

Or ditch the frames.

Or ditch the silly menus.

Or both.

--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/20...ces-ie-is-dead

[MP Multimedia]

That was no help at all. lol

"David Dorward" <do*****@yahoo.com> wrote in message
news:be*******************@news.demon.co.uk...

MP Multimedia wrote:

I'm using a hierarchical menu made in javascript.

Uh oh. That's very difficult to do right (some would say its impossible)

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.

You _need_ to change to frames? Why are you moving backwards? Even the
inventor of frames (Netscape) removed them from their homepage after 6
months becuase they realised how much they sucked.

http://stone.thecoreworlds.net/www/frames/

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?

Create identical content in the other frames and line them up very very
carefully.

Or ditch the frames.

Or ditch the silly menus.

Or both.

--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/20...ces-ie-is-dead

[David Dorward]

Richard Cornford wrote:

I am optimistic and believe that a hierarchical menu script can be
written to address the problems of cleanly degrading on JavaScript
disabled and unsupportive/insufficiently dynamic browsers,
accessibility
There are two big problems with h-menus in general.

(1) people with motor skill problems (although activating onclick and
onfocus can go a long way to dealing with this).

(2) People using screen scrapers. Its unfortunate that most software
products for reading webpages aloud are not true aural browsers (parsing
the HTML, and applying aural CSS), but instead are Internet Explorer screen
scrapers. From what I hear, they don't react well to pages gaining new
visible elements dynamically.
David's other proposal (I suspect tongue in cheek)

I have been known to go tongue in cheek, but this time I was serious. Its
difficult, impractical and time consuming - but just about possible.
--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/20...ces-ie-is-dead

[MP Multimedia]

Thank you Richard for explaining this to me. Your explanation was very
helpful.

The reason I have to add frames on the page is because the client
specifically asked for it. And the menu has already been validated by him.

I forgot about search engines not reading framesets, that is a good reason
not to use them.

I guess what I have to do now is convice my client not to use pages with
framesets.

Thanks again.

___________________

Marie-Perle
www.mpmultimedia.ca
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:be*******************@news.demon.co.uk...

"MP Multimedia" <mp**********@videotron.ca> wrote in message
news:Z9********************@wagner.videotron.net.. .

I'm using a hierarchical menu made in javascript.

Uh oh. That's very difficult to do right (some would
say its impossible)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.You _need_ to change to frames? Why are you moving backwards? ... <snip>http://stone.thecoreworlds.net/www/frames/

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?

Create identical content in the other frames and
line them up very very carefully.

Or ditch the frames.

Or ditch the silly menus.

Or both.

That was no help at all. lol

It may not seem to be much help but David has laid out the options much
as I see them. He clearly prefers the "ditch the frames" solution and I
also think that would be the simplest solution. Re-thinking the
reasoning behind the choice of a frameset; are they really the only way
of achieving the desired results?

Re-thinking the choice of navigation is the next option. Given a
frameset, is hierarchical menu style navigation appropriate? Menu
scripts are not easy, a lot of the time they are written in the
optimistic belief that they will only ever be exposed to one ore two
versions of the commonest browsers with JavaScript enabled, and when
exposed to anything else the navigation vanishes. Leaving
non-run-of-the-mill visitors and search engine robots wondering why they
bothered and moving on to the next site on their list.

I am optimistic and believe that a hierarchical menu script can be
written to address the problems of cleanly degrading on JavaScript
disabled and unsupportive/insufficiently dynamic browsers,
accessibility, keyboard navigation, etc, etc. In fact I was working on
such a script yesterday, but I haven't even finished working out what
all the issues are, let alone come up with strategies for tackling them
all yet. And David is right, "very difficult to do right" is no
underestimation, and navigation is something than needs to be done
right.

David's other proposal (I suspect tongue in cheek) is the only option
that stands a chance of working with frames cross-browser. Reproducing
the menu in each frame and lining them up is doable in at least the
major browsers. It requires different approaches to working out the
differences in the positions of the frame view-ports to take into
account the apparent absence of standardisation in frameset DOMs. And a
truly general solution is probably impractical, as that would be
required to handle indefinitely nested framesets and iframes. There is
also an added complexity because exposing elements that extend beyond
the frame's view-port will often also bring scroll bars into existence
so it is probably best to also be clipping each element to the
constraints of its own view-port. In all, a big complex script that
would probably be best tailored to a specific frameset and is still
going to be difficult to arrange to cleanly degrade to usable navigation
of unsupportive browsers.

Richard.

[Richard Cornford]

"David Dorward" <do*****@yahoo.com> wrote in message
news:be*******************@news.demon.co.uk...

I am optimistic and believe that a hierarchical menu script
can be written to address the problems of cleanly degrading
on JavaScript disabled and unsupportive/insufficiently
dynamic browsers, accessibility
There are two big problems with h-menus in general.

(1) people with motor skill problems (although activating
onclick and onfocus can go a long way to dealing with this).

Yes, keyboard navigation is essential, though that is as much for laptop
users who have learnt all the keyboard shortcuts (so they can avoid
using the built in "pointing device") as anyone else.
(2) People using screen scrapers. Its unfortunate that most
software products for reading webpages aloud are not true
aural browsers (parsing the HTML, and applying aural CSS),
but instead are Internet Explorer screen scrapers. From what
I hear, they don't react well to pages gaining new visible
elements dynamically.

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? In the latter case it would make most sense to never
implement the interface at all as at least that could be detected by a
script.

The thing that seems to distinguish h-menus from the tree-menu
alternatives is the need to use CSS that will potentially render the
contents of the nested ULs [1] inaccessible (display:inline; on the top
level items and position:absolute;, visibility:hidden;/dispaly:none; on
the sub menus). 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.

The viability of the exercise hangs on the ability of the script to make
the right decision about writing out that STYLE section. If it decides
not to then it only has to disable it's own initialisation routine and
everything degrades to a usable UI. If it decides to insert the STYLE
section it must be 100% certain that the browser will fully support the
menu script and that the result will be suitably usable UI. I am
confident that detecting suitably dynamic browser support is realistic
but, as you point out, being confident that the result will be a usable
UI under all circumstances is another question. I will have to resolve
that question to my own satisfaction through experimentation, which will
either tell me how it can be done or why it cant be done (either of
which will be useful knowledge).

David's other proposal (I suspect tongue in cheek)

I have been known to go tongue in cheek, but this time I was
serious. Its difficult, impractical and time consuming - but
just about possible.

I didn't mean to imply that you did not think that it was doable. I was
hoping to suggest that its presence in the list was merely to provide a
comprehensive list of alternatives and that you were not presenting it
as a realistic course of action. Given your undisguised preference for
the elimination of frames and your describing the simultaneous aligning
of elements across a frameset as "difficult, impractical and time
consuming" I don't think that you do consider it a realistic course of
action when compared with your 3 other suggestions.

A few weeks ago I wrote a script that aligned a DIV in each frame of a
frameset (to the mouse pointer) in response to a question on the group.
It was not good enough to be more than a demonstration of the principal
but it was enough to give me a reasonable handle on the issues. I learnt
that it would be much easier to tailor such a script to a known
frameset, which is why I don't think that there will be an adequate
off-the-shelf solution available. I am confident that it can be done (to
the extent that the menu itself can) but the prospect of layering that
requirement on top of the menu script and implementing it for each page
that may pass through the frameset is daunting.

Richard.

[1] Like many others, I have concluded that nested ULs are the only
sensible mark-up to use as the basis for this type of menu, as they
offer a familiar and usable presentation of the hierarchical navigation
structure in the absence of both CSS and JavaScript.

[David Dorward]

MP Multimedia wrote:

The reason I have to add frames on the page is because the client
specifically asked for it.

Client: "Fix my car! Use this spanner!"

Mechanic: "But my collection of spanners include ones that will do the job
efficiently! That won't even fit!"

--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/20...ces-ie-is-dead

[Foobus Barrius]

On Fri, 11 Jul 2003 20:12:23 +0100, David Dorward <do*****@yahoo.com>
wrote:

MP Multimedia wrote:

The reason I have to add frames on the page is because the client
specifically asked for it.

Client: "Fix my car! Use this spanner!"

Mechanic: "But my collection of spanners include ones that will do the job
efficiently! That won't even fit!"

That's right. Tell your client to go to hell. And don't forget to
screw his wife and kick his cat on your way out the door.

[David Dorward]

Foobus Barrius wrote:

That's right. Tell your client to go to hell. And don't forget to
screw his wife and kick his cat on your way out the door.

No, point out that you are the expert and that while the technology he
thinks is good may work for him, it will cause major problems for at least
some of his customers.

If the client was an expert at web authoring, he probably wouldn't hire
someone else to do it for him. (And if I was an expert at fixing cars
Iwouldn't hire a mechanic)

--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/20...ces-ie-is-dead

[MP Multimedia]

Now my client wants 4 frames on the site.

I found a hier menu at www.dynamicdrive.com to be used with frames. Trying
it.

___________________

Marie-Perle
www.mpmultimedia.ca

"David Dorward" <do*****@yahoo.com> wrote in message
news:be*******************@news.demon.co.uk...

Foobus Barrius wrote:

That's right. Tell your client to go to hell. And don't forget to
screw his wife and kick his cat on your way out the door.

No, point out that you are the expert and that while the technology he
thinks is good may work for him, it will cause major problems for at least
some of his customers.

If the client was an expert at web authoring, he probably wouldn't hire
someone else to do it for him. (And if I was an expert at fixing cars
Iwouldn't hire a mechanic)

--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/20...ces-ie-is-dead

[Jim Ley]

On Fri, 11 Jul 2003 17:57:32 +0100, "Richard Cornford"
<Ri*****@litotes.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.javascript FAQ - http://jibbering.com/faq/

[Richard Cornford]

"Jim Ley" <ji*@jibbering.com> wrote in message
news:3f****************@news.cis.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
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.

I realise that it is risky and needs very cautions handling. I never did
intend to write out display:none; or visibility:hidden; at that point
(really a job for onload). Mainly I was thinking of position:absolute;
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.