A lot of problems are actually really simple if you "just" do caching properly. But, you know what? In general, caching is really hard to do properly. I think the problems with the back button stem from ambiguity in what back actually means. Does it revert a form transaction? Does it restore the cached value of the previous page? Does it go back to the previous URL, updating the content? Since the web uses a stateless protocol, it's unclear to what extent the cache is still valid.
(Also: Does anybody else find articles with large, semi-relevant images between nearly every paragraph to be incredibly irritating?)
I think the description provided in the article is pretty unambiguous. Perhaps other people might want different behaviours but what was described is the article is exactly what I want.
I don't care if the cache is valid. I don't care if the webmaster thinks the page needs to be updated every 10 seconds. All I want is the previous page exactly as it was when I last viewed it. It's my browser and it should do what I want. If the webmaster is relying on browser behaviour to ensure I don't resubmit a form then frankly they are asking for trouble.
And I think his observation on back vs. browser tabs is very insightful. When browsing links, as on HN, I always open a new link in a new tab. And I think the reason is exactly what he says: I don't trust the back button to get me back to the right place quickly. Killing a tab does do that, and so I use tabs.
The web browser has very little to do with this problem; it is merely doing what the website has told it to do (or not to do).
I run a small forum where clicking back and forth between forms without losing what you've typed is a very important feature. It works exactly the way this author wants in all browsers because the headers are set correctly.
Similarly, I also work on a big web application where clicking the back button and getting stale information is bad. Again, the website sets the proper headers and the information is refreshed (if appropriate) or left alone (if appropriate).
This is not a browser issue. The differences are likely caused by how different browsers implement (or don't implement) the standard.
Perhaps the problem lies with what the browser does when no cache control headers are present? I just checked with by loading and then leaving a Guardian.co.uk page, and Safari reloads it from server when you click back. Checked both the page headers and the HTTP headers, and there's no expiry date set anywhere.
My preference in this case would be for back to work "properly" unless a site explicitly requests a reload.
Doing it that way would solve another back issue that stings me from time to time that the author doesn't mention: forms. I'll have filled out a form, hit submit and hit a network snag for some reason or other. Try to hit back to rescue all that typing, and the browser tries to reload the damn form. Stuck.
When I hit back, all I want is to go to the previous page, instantly, precisely as I saw it when I clicked the link to take me away. No reloading, nada.
A lot of so called "browser problems" are actually website problems.
And who's the genius that decided accepting malformed html was a good idea? If the first browsers gave an error (with line numbers and explanations) instead of trying to render incorrect html people would just go back and fix it.
I've taught a lot of people the basics of HTML. Always started the same: open a text file, type in "Hello World", save as .html, open in browser, see Hello World. Woohoo, instant rush, this stuff isn't so complex after all. Don't want to see this:
Your argument is that you've started teaching a lot of people HTML by showing them something that has nothing to do with HTML, clap clap clap clap clap clap clap...
Most of the enhancements made in HTML over the last few decades would be impossible if browsers didn't render incorrect HTML. Even simple things, like having closed single tags (<br/> vs. <br>) is only possible because old browsers are really forgiving.
Yeah, this has annoyed me for a long time. I believe Opera comes closest to this ideal. Actually, it might even meet all of the criteria already. It's a shame I can't use it.
Edit: I think the only complete answer going forward is to treat it like suspending a machine. An open web page today is a running application with state. It would have to be frozen when you go to another page (so that it doesn't do stuff while you're gone), and resumed when you click the back button.
In some ways, it would be suspending a machine: if a textbox were really a <canvas> controlled by Javascript, you'd have to suspend the Javascript VM state in order to still have the text upon going back.
Yes, exactly, assuming you're using a JS VM. But I'm saying you'd have to preserve the JS state anyway, because anything on the page could depend on it.
Not just JS state, either. What if I have a flash movie running? When you middle-click a link on a YouTube video, the video keeps playing. You probably don't want pages in your history to be downloading data, playing video, etc. Ideally, you'd probably want it to start playing right where you left it when you click back.
What about if the thing in my history is a 1gb video file, and I type "gmail.com" in the address bar. I have Firefox set to remember my state between sessions, and I rarely close my gmail tab. So, that video file might stay in my back-button history for months. Is it reasonable to expect it to freeze the video player's state and keep hold of that forever, every time the browser starts up? That'd probably suck.
So, the author's suggestion isn't quite perfect. It's close, but misses some important edge cases, and misses the point of why this is very hard to do right.
As I hadn't ever really noticed this problem, I decided to see what would happen if I hit the back button in firefox after disabling my wireless adapter. After reading the article, I was quite surprised that it went back to HN perfectly. I also tested it with a longer back/forward history. In one attempt, I was able to back/forward through seven pages(that's all that I had been to in that tab at the time) without having internet access. Is there some subset of web sites for which this wouldn't work properly, as the author seems to be saying? Is the subset of scenarios in which the back button works only a small portion of typical scenarios?
I think if Firefox knows you're online, it will hit the server (sending e.g., If-Modified-Since), but if you go offline, it can tell and puts itself in offline mode, where it browses from the cache only. You can do the same experiment just by doing File - Work Offline.
Ah. Of course. I didn't consider that possibility. Now I've tried back/forward while connected to the internet and looking at Network Usage in Activity Monitor. I noticed that most of the times when I hit back/forward, there was no network traffic. I expect most of the traffic I did notice was either due to cache refreshes or due to other apps(probably mostly Thunderbird) I have running.
The author seems to be completely ignoring the fact that sometimes navigation SHOULD be one-way only.
If the link or button you've clicked on makes a change on the server that affects that page, it might not make sense to display the old page when you hit Back.
For example, you were on the edit page of a list of messages you want to send to another user on the site. You finished making changes and clicked "Send". Now you’re on a page with a message saying, "Messages Sent!". What do you expect when you click the Back button?
1. The edit page with the list of “pending” messages that have actually already been sent?
2. The edit page with an empty list of messages or the original messages but now with a “sent” status?
I’d argue that the second option is far less confusing for a user, but that’s not what you’ve suggested should happen.
And what happens if you click Send again? In the first case, you could send the same messages again, or maybe the server will reply with, "I don’t know what you’re talking about - those messages are already sent". There’s no way for a user to know!
Caching is all good and well, but sometimes you really don't want a page to be cached. That's why there are headers for caching...
Great, now my browser can use even more memory! I suppose that could be mitigated if there was an option for the number of pages to hold open for the back button this way for each tab and window.
Yup - if I want to come back here, I'll use a new tab. If I don't, click through, and it's gone forever (not just 'hidden' in memory on my noticeably a slower machine).
What's that - I need to go back? My fault, I deal with it, I'm not paying someone $1000 to fix my stuff-ups.
This article singles out Safari on the iPhone, saying that it supports "tabs". Ironically, iPhone Safari's "tabs" behave exactly like this broken back button behavior -- I've noticed that often when I switch back to an old tab on my iphone, the page is often refetched (losing my position and any form content) because it was unloaded while I was browsing on another tab.
I agree with what they've said and I wasn't going to comment but.. I clicked back to come back to Hacker News and it was instant. Like, not even 100ms to do a modification check or anything. Bam. It's there. Perhaps this is a Safari 4 beta thing?
No, Firefox is just the same. It's really a web server thing - there is such thing as 'caching', although OP seems to want to override such directives for all pages and have them all cached.
My main gripe with 'back' in Safari is the keyboard shortcuts. I can press the back button to go to the previous page, I cab press it with command to open it in a new tab, I can press backspace to go to the previous page, then why can't I press command backspace to open the previous page in a new tab?!
Users don't need to know anything about how things really work to complain about usability problem. This is actually one of the most useful feedback developers can get.
> The reason tabbed browsing is so popular, is because you can work on several apps and websites at the same time.
Close, but not quite... Before tabs, you could still have multiple pages open, but they each took up a window. Tabs are simply a streamlining of the multi-window process. (And Chrome actually makes efforts to blur this distinction.)
This author has a really strange concept of what the "back button" should do - probably very different than what most developers (this crowd?) would think.
He said "click here (insert random link)" then knowing that we would all ctrl-tab back to the original article he was showing how backing up SHOULD work. I.E., bringing you to right where you were previously and doing it fast, without reloading the page.
(Also: Does anybody else find articles with large, semi-relevant images between nearly every paragraph to be incredibly irritating?)