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

https://www.mpmultimedia.ca

[David Dorward]

Re: Hier menu in frameset

MP Multimedia wrote:[color=blue]
> I'm using a hierarchical menu made in javascript.[/color]

Uh oh. That's very difficult to do right (some would say its impossible)
[color=blue]
> 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.[/color]

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/

[color=blue]
> The menu is on the top frame and when hovering the categories, the
> sections appear under the left and right frame.[/color]
[color=blue]
> How do I solve that problem?[/color]

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/2003/5/30/microsoft-announces-ie-is-dead

[MP Multimedia]

Re: Hier menu in frameset

That was no help at all. lol

"David Dorward" <dorward@yahoo. com> wrote in message
news:beknk0$n17 $3$8300dec7@new s.demon.co.uk.. .[color=blue]
> MP Multimedia wrote:[color=green]
> > I'm using a hierarchical menu made in javascript.[/color]
>
> Uh oh. That's very difficult to do right (some would say its impossible)
>[color=green]
> > 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.[/color]
>
> 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/
>[color=green]
> > The menu is on the top frame and when hovering the categories, the
> > sections appear under the left and right frame.[/color]
>[color=green]
> > How do I solve that problem?[/color]
>
> 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[/color]

[David Dorward]

Re: Hier menu in frameset

Richard Cornford wrote:
[color=blue]
> 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[/color]

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.
[color=blue]
> David's other proposal (I suspect tongue in cheek)[/color]

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/2003/5/30/microsoft-announces-ie-is-dead

[MP Multimedia]

Re: Hier menu in frameset

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

https://www.mpmultimedia.ca

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
news:bellsg$jfq $1$830fa17d@new s.demon.co.uk.. .[color=blue]
> "MP Multimedia" <mpmultimedia@v ideotron.ca> wrote in message
> news:Z9pPa.1252 7$Pe2.380839@wa gner.videotron. net...[color=green][color=darkred]
> >>> I'm using a hierarchical menu made in javascript.
> >>
> >>Uh oh. That's very difficult to do right (some would
> >>say its impossible)[/color][/color]
>[color=green][color=darkred]
> >>>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.[/color][/color]
>[color=green][color=darkred]
> >>You _need_ to change to frames? Why are you moving backwards? ...[/color][/color]
> <snip>[color=green][color=darkred]
> >>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.[/color][/color]
>[color=green]
> >That was no help at all. lol[/color]
>
> 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.
>
>[/color]

[Richard Cornford]

Re: Hier menu in frameset

"David Dorward" <dorward@yahoo. com> wrote in message
news:belv6q$4k9 $1$8300dec7@new s.demon.co.uk.. .[color=blue][color=green]
>>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[/color]
>
>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).[/color]

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.
[color=blue]
>(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.[/color]

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:absolu te;, visibility:hidd en;/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).
[color=blue][color=green]
>>David's other proposal (I suspect tongue in cheek)[/color]
>
>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.[/color]

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]

Re: Hier menu in frameset

MP Multimedia wrote:
[color=blue]
> The reason I have to add frames on the page is because the client
> specifically asked for it.[/color]

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/2003/5/30/microsoft-announces-ie-is-dead

[Foobus Barrius]

Re: Hier menu in frameset

On Fri, 11 Jul 2003 20:12:23 +0100, David Dorward <dorward@yahoo. com>
wrote:
[color=blue]
>MP Multimedia wrote:
>[color=green]
>> The reason I have to add frames on the page is because the client
>> specifically asked for it.[/color]
>
>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!"[/color]

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]

Re: Hier menu in frameset

Foobus Barrius wrote:[color=blue]
> 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.[/color]

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/2003/5/30/microsoft-announces-ie-is-dead

[MP Multimedia]

Re: Hier menu in frameset

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

https://www.mpmultimedia.ca

"David Dorward" <dorward@yahoo. com> wrote in message
news:bendut$q38 $2$8302bc10@new s.demon.co.uk.. .[color=blue]
> Foobus Barrius wrote:[color=green]
> > 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.[/color]
>
> 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[/color]

[Jim Ley]

Re: Hier menu in frameset

On Fri, 11 Jul 2003 17:57:32 +0100, "Richard Cornford"
<Richard@litote s.demon.co.uk> wrote:
[color=blue]
>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?[/color]

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.
[color=blue]
> 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.[/color]

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]

Re: Hier menu in frameset

"Jim Ley" <jim@jibbering. com> wrote in message
news:3f101358.1 82836154@news.c is.dfn.de...[color=blue][color=green]
>>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?[/color]
>
>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.[/color]

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).
[color=blue]
>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.[/color]

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 :).
[color=blue][color=green]
>>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.[/color]
>
>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.[/color]

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:-
[color=blue]
>Have you seen my (now very old) approach?
>http://jibbering.com/accessibility/[/color]

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]

Re: Hier menu in frameset

"Jim Ley" <jim@jibbering. com> wrote in message
news:3f116e69.1 014679@news.cis .dfn.de...[color=blue][color=green]
>>In the event of a form submission being
>>aborted by a validation script ...[/color]
>
>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.[/color]

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.
[color=blue][color=green]
>>It might also prove the only answer to the point that David raised
>>about screen readers working with IE.[/color]
>
>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.[/color]

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.