Broken Browsers Part One: The Back Button
blog.dreamhost.com
blog.dreamhost.com
(Also: Does anybody else find articles with large, semi-relevant images between nearly every paragraph to be incredibly irritating?)
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.
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.
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.
Error at line 1, DOCTYPE expectedBrowsers are just following this basic networking principle.
I don't agree. It's my browser. It should do what I want it to do, not what the website wants it to do.
And what I want it to do is exactly what this guy says.
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.
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.
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.
Other than that, I have no idea what this topic is about. Going back works fine for me in all the ways he mentioned.
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...
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.
And get rid of the pictures, it's annoying.
Oh, come on now. The reason tabbed browsing is so popular, is because you can work on several apps and websites at the same time.
Please make your points without making stuff up. It's annoying.
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.)
Click this link.
That should have opened in a new window (or tab) for you. And if you’re back here now, you’ve switched windows or tabs, correct?"
Fail. It opened a new window with a page I had never visited before.
Of all the interpretations of the back button, I'm pretty sure that's not one of them.
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.