Preserving state

[Karl]

This might not really be a javascript question, but I'll start with this
group.

At http://www.gazingus.org/ there is a very nice collapsible menu written
using CSS and Javascript

Using Lists for DHTML Menus
HTML lists, along with well-placed CSS and JavaScript, result in flexible
dynamic menus that gracefully degrade in older browsers.<<<<<< <

Does anyone have any ideas as to how I might go about modifying the code so
that the menu will remember its open/close state from one screen refresh to
the next.

TIA

[Thomas Mlynarczyk]

Also sprach Karl:

Does anyone have any ideas as to how I might go about modifying the
code so that the menu will remember its open/close state from one
screen refresh to the next.

There are three ways of preserving information across page loads/refreshes:

1) Put the info in the query string, like
"mypage.html?me nu1=open&menu2= closed", but that will not work for refreshes,
as you must explicitly set the query string. But you could use it with menu
links which you would then have to generate dynamically or modify their
query string property with JavaScript. However, this would be quite a
complicated solution.

2) Set a cookie. Disadvantage: will not work if users have cookies disabled.
But otherwise this seems to be the simplest solution.

3) Embed your page in a frameset and store the info there. If you are using
frames anyway, this would be *the* solution for you. If your site is
frameless, you may frame it in a frame stretching over the whole window.
This way, you could even avoid some frame-related problems.

4) Use the onunload event to "redirect" to the same page with the query
string set. (This is probably the worst solution as you are thereby
preventing your visitors from ever leaving your site.)

My conclusion: Use cookies for a frameless page and the top level frame for
a page using frames. But then: is it really that bad if your menu reappears
closed upon refresh? Another possibility might be to implement the menu in
such a way that the menu, "onload", figures out by itself which main page is
being shown and opens itself accordingly.

[Thomas 'PointedEars' Lahn]

Thomas Mlynarczyk wrote:

3) Embed your page in a frameset and store the info there. If you are using
frames anyway, this would be *the* solution for you. If your site is
frameless, you may frame it in a frame stretching over the whole window.
This way, you could even avoid some frame-related problems.

What problems with frames you can avoid with this are you writing
about? With frames you can only get more in trouble than without
them. Making bookmarking worse is only one of the prob^W challenges
you will encounter then. For I know you understand German, read

http://www.subotnik.net/html/frames.html
PointedEars

[Thomas Mlynarczyk]

Also sprach Thomas 'PointedEars' Lahn:

3) Embed your page in a frameset and store the info there. If you
are using frames anyway, this would be *the* solution for you. If
your site is frameless, you may frame it in a frame stretching over
the whole window. This way, you could even avoid some frame-related
problems.
What problems with frames you can avoid with this are you writing
about? With frames you can only get more in trouble than without
them. Making bookmarking worse is only one of the prob^W challenges
you will encounter then.

The actual problem that arises with regard to bookmarking is that you might
accidentally bookmark the "menu" frame, or that you will end up with an
unframed page (where vital elements such as the navigation) are missing -
this also happens when you get to the page from a link found in a search
engine. As for bookmarking itself (as well as printing a web site by the
way) I have always been of the opinion that the correct handling of this is
entirely the browser's responsibility. If a browser supports frames, the
manufacturer could easiliy implement a correct handling of bookmarks which
takes into account the special needs of framesets. Besides, users should
know how to handle their own user agent.

But to get back to the point: Normally, when someone clicked a link to one
of your subpages, you would use JavaScript to load the frameset. A problem
arises, when the user has JavaScript disabled. But in the case we have here,
it seems that the site relies upon JavaScript and even if it did not, the
user would not notice any difference as there would be just one frame
stretching over all the window and the actual frameset would be a mere
"backstage" technical structure. So the problem of loading the frameset
(which includes bookmarking) would not appear in this case as the frameset
would not contribute to the visual presentation but just serve as a storage
device for JavaScript data.

Of course: If a page is designed frameless, it would not be very elegant to
add a "blind" frameset just for the sake of storing variables. In such a
case I would not recommend the frame solution. But if the OP uses frames
anyway (I don't know if he does), the frameset would indeed be the perfect
place to store the data.
http://www.subotnik.net/html/frames.html

I know this one - and many others like it. I've read them, thought about
them and all in all I have now - I think - a very good understanding
concerning frames, their use, their advantages and disadvantages as well as
problems which must be solved when using them.

[Thomas 'PointedEars' Lahn]

Thomas Mlynarczyk wrote:

Also sprach Thomas 'PointedEars' Lahn:

3) Embed your page in a frameset and store the info there. If you
are using frames anyway, this would be *the* solution for you.
If your site is frameless, you may frame it in a frame stretching
over the whole window. This way, you could even avoid some
frame-related problems.
What problems with frames you can avoid with this are you writing
about? With frames you can only get more in trouble than without
them. Making bookmarking worse is only one of the prob^W
challenges you will encounter then.

The actual problem that arises with regard to bookmarking is that you
might accidentally bookmark the "menu" frame,

No, the problem is that without a context menu, in graphical browsers
you can only bookmark the frameset.
I have always been of the opinion that the correct handling of this
is entirely the browser's responsibility.
The UA knows only the URI of the frameset if one selects "Add To
Bookmarks" from the main menu. That is likely to happen here since
the user does not expect that he is required to use the context menu
of the frame, if there is any.
But to get back to the point: Normally, when someone clicked a link
to one of your subpages, you would use JavaScript to load the
frameset.
I have done that until a month before, but I am not doing it any longer.
Instead, I write a link dynamically for visitors to reload the frameset
*if* they want that. Never serve what has not been ordered.
A problem arises, when the user has JavaScript disabled.
But in the case we have here, it seems that the site relies upon
JavaScript
So bad design justifies worse design?
and even if it did not, the user would not notice any
difference as there would be just one frame stretching over all the
window and the actual frameset would be a mere "backstage" technical
structure.
Visitors will note a difference when they look into the Location Bar.
They will never know which part of a website they navigated to, unless
you provide breadcrumbs or stuff like that in *every* (frame) document.
So-called "cloaking" is a Bad Thing and should be discarded/disabled.
So the problem of loading the frameset (which includes bookmarking)
would not appear in this case
True.
as the frameset would not contribute to the visual presentation but
just serve as a storage device for JavaScript data.
Definitely wrong.
Of course: If a page is designed frameless, it would not be very
elegant to add a "blind" frameset just for the sake of storing
variables. In such a case I would not recommend the frame solution.
But if the OP uses frames anyway (I don't know if he does), the
frameset would indeed be the perfect place to store the data.

The perfect solution is to remove the frameset if there is one and
there is something better (CSS overflow:scroll for example, I am
currently working on that). A suboptimal solution will at least
include a no-frames part so that if frames are disabled (Opera can
do that) or not even supported, one gets useful and usable content.

I would rather bother with cookies if properly explained than bother
with a site which documents I cannot bookmark (from the newbie
perspective) only because the author is incompetent enough not to use
server-side sessions to store his settings (from the professional
perspective).
PointedEars

[F. Da Costa]

Hi,

I am aware of the 'age' of this post but I thought I would ask the question
nonetheless (no i've already got ;))

Thomas Mlynarczyk wrote:

3) Embed your page in a frameset and store the info there. If you are using
frames anyway, this would be *the* solution for you. If your site is
frameless, you may frame it in a frame stretching over the whole window.
This way, you could even avoid some frame-related problems.

Using simple things like strings this would work but have you ever tried
this using IE5+ and an object like table?

Thx,
Fermin DCG

[Thomas 'PointedEars' Lahn]

F. Da Costa wrote:

Thomas Mlynarczyk wrote:

3) Embed your page in a frameset and store the info there. If you are using
frames anyway, this would be *the* solution for you. If your site is
frameless, you may frame it in a frame stretching over the whole window.
This way, you could even avoid some frame-related problems.

Using simple things like strings this would work but have you ever tried
this using IE5+ and an object like table?

What do you mean? What is "an object like table"?

The type of data to be stored in the frameset "window" object's property
does not matter, not even in IE 5+. What matters is whether the DOM
allows you to add properties to the frameset's "window" object, if there
is any, or not. (In IE 5+ it does.) But that does not make this bad
approach of preserving data while navigating any better.
PointedEars

P.S.
Please separate quote and new text by an empty line which makes your
postings more legible.