At 11:07 AM -0400 2001-10-04, Chris Casciano wrote:
>Well, with all due respect i disagree.
Heavens, whoever said I was due any respect? Flame on! :)
>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.
Here I disagree.
Clicking Back for most users is a kind of Undo--"whoops, this page
didn't have what I wanted, let me back up and try again". Obviously
if the browser's behavior is designed to carry out this desire, the
page should be left as it were.
Clicking Refresh is the opposite--"Please start this page over, as
though I've never seen it before."
Somewhere in between the two is the debate of how a page should
behave when you use HTML to navigate to it after having visited it. I
think the argument could be made both ways. One one hand you've
already been there...the page should know that and treat you as such,
greeting you as you left it. On the other hand, I'm certain people
will be able to come up with an example of dynamic pages which should
always pretend they've never seen you before.
Complicating (and at the same time deciding) this argument is the
issue of implementation. If IE was going to let navigated-to pages
greet you with a cached state, that means it needs to cache them. And
due to memory and disk constraints some will be cached, and some not.
For those which are, the browser can show the saved state of the
page. For those which aren't, the browser will have to reload/rerun
the page from scratch. The user should be insulated from this
underlying problem, and not have to experience IE behaving
inconsistently.
[I know, the same implementation problem occurs with caching pages in
the history for "Back" usage. But to a far lesser extent.]
It is therefor my opinion that it is desirable for IE to treat the
Back button differently from links to the same page:
a) It is desirable for IE to treat the "Back" button as a return to a
saved state.
b) It is desirable for IE to treat links to pages as a reload/refresh.
>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.
This is a very good point. IIRC, previous versions of IE behaved
badly in the other direction: returning to the page via the back
button showed the page in its initial state and did NOT run the
onload code. Very frustrating. There seems to now have been
overcompensation in the opposite direction.
A restored-from-cache page should EITHER show the state it was in
previously OR show the initial state and fire the onload event, but
NOT both. [And IMO, the former is the desirable behavior for pages
returned to via the "Back" button or javascript.back(), and the
latter preferable for pages returned to via HTML links to the page or
location.href='...'.]
>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.
Certainly true, but now you're picking at an example I came up with,
not the point itself. Let's take the example of your page. Pretend
your a use of your site. You come to the home page and see a cool
animation showing how the navigation works. You click a link. You
decide to go Back. Do you want to watch the animation again, or just
start using the page as it was?
>Yes, I could always init the position via javascript, and I may now have to
>if this behavior persists.
Why not do the first solution I mentioned--set a "global" (window)
variable which flags whether or not the items have moved:
var navInPlace=false;
function MoveNav(){
if (navInPlace) return;
...
navInPlace=true;
}
window.onload=MoveNav;
>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.
True 'nuff. However, you could use JS to access the css rule for the
divs and find out what it specifies. But I'd do the solution with the
flag before I went this route.
--
Gavin Kistner
User Experience Architect > Refinery, Inc.
[EMAIL PROTECTED] | 1.314.283.1443
To unsubscribe send mail to [EMAIL PROTECTED]
To search the archives:
<http://www.mail-archive.com/macie-talk%40lists.boingo.com/>
