on 10/4/01 10:40 AM, Gavin Kistner at [EMAIL PROTECTED] wrote: > At 10:10 AM -0400 2001-10-04, Chris Casciano wrote: >> With javascript I then slide the elements into their proper position on the >> screen. However, when returning via the BACK button (CMD+left arrow), or >> FORWARD, the position of the elements are *not* returned to their top of >> -25px before the function called onload begins to move them. > > IMO this is a feature, and a flaw in your page logic. > > When I press the back button to return to a page I have just left, I > would prefer that IE bring up the page in the state that I left it. > If I had chosen a drop-down item from a form, I want that drop-down > still selected. If I've interacted with the page and DHTML has caused > the items to spin and move and settle in new locations and bring up > new options, I want to see them like that when I return. > > (Imagine, for example, a nested-tree DHTML navigation system, which I > expanded three levels deep to find the link to the page I wanted. > When I return to the page, that dhtml menu should remain open.) > > IE seems to be doing this--properly (IMO) caching the location of the objects. >
Well, with all due respect i disagree. First, if IE/mac was doing this intentionally for the benefits of a scenario that you outline I find it quite hard to believe that the browser would not have been coded to behave the same way if I instead clicked on th "go home" link on the 2nd page. This behaving differently based on how you return to a page would seem very disorienting to me as a visitor, especially in a tree environment like you outlined. Secondly, the function I've written to move the elements is triggered via body.onload. In the scenario you've outlined, the page isn't behaving like its *loading* anymore, but more like its frozen in time as if it the user was flipping between open browser windows. If it was an intentional move to skip the positioning in the css I would thing that skipping anything triggered via body.onload would go hand in hand with that. And finally, if as a page developer you felt that it would benefit your visitors to maintain the state of your 'tree' on your pages you already have the tools to do that. Using cookies with your script would work across browser and platforms, as well as solving the problem mentioned above of different methods of returning to a given page. > Assuming IE also caches the values in objects assigned to the window, > you can fix your script to work with browsers which reset the page or > don't by simply setting a variable after the menu has moved, and then > not moving them if that flag is set. (Or your moving script could set > them to a known location before attempting to move them, rather than > assuming that they're always at the top.) Yes, I could always init the position via javascript, and I may now have to if this behavior persists. My major problem with this method is I would then have to have the value in 2 places - once in my css so browsers like NN4 work, and a second time in javscript so IE/mac works. Seems like cause for maintenance problems to me. -- name://chris aka://10sball http://placenamehere.com To unsubscribe send mail to [EMAIL PROTECTED] To search the archives: <http://www.mail-archive.com/macie-talk%40lists.boingo.com/>
