Infinite scrolling + back button

Question

Sometimes whilst bored I read old xkcd's annd although I know all the comics, I do from time to time discover a title text I hadn't seen before. This time I came across

Which had the title text: "Maybe we should give up on the whole idea of a 'back' button. 'Show me that thing I was looking at a moment ago' might just be too complicated an idea for the modern web."

This made me think, would it be a good UX practice to make the back button scroll up the page instead of going back a normal URL? And have a refresh load up that specific place in the infinite list instead of the top of the list. As far as I can see there is no technical reason not to do this, yet I haven't seen this implemented anywhere, so I am hereby asking whether you guys know of anybody who researched and/or implemented this? And if not just for opinions which disadvantages this approach could have. (Or a simple 'Yes you should do that!' if none of the before applies).

---

Example for the UX folk

You are on BBC.co.uk and go to Facebook. You scroll down a couple of pages, when you hit the back button, instead of going back to BBC you just scroll up one page. Till you get up till the first, after which you would after all just go back. When you copy the URL and bookmark it you are able to find the post you were just looking at (and still scroll up for more posts up till the most recent one).

---

Tech details for the Tech folk

With the History API in the browser you can change the URL at any time, so when you would scroll down you would see the URL change the ?p=n (or in the above example t=i) part all the time. Going back would thus just go back to the previous URL state. (The facebook example would require a simple interaction between replaceStates all the time and a single pushState per page).

Answer 1

Since the infinitely scrollable page has no real world parallel, perhaps the function of the back button can exist without a real world metaphor.

Imagine that you have been scrolling down an infinite page, pausing for some parts and zipping past others. Now imagine that you tap the back button. What is your intention? too jump back up to the most recent part which you paused on? go back to the top of the page, or maybe you want to leave the scrolling page entirely. It is impossible for the page to know from that single button click, what you desire.

So the page should ask you what you meant by that back click, and it should ask in the least obtrusive manner available.

Split the screen vertically, and leave half showing the current point on the infinitely scrolling page. In the other half, show a menu offering title-text from the last few scroll points which you paused for. Add a button for "top of page" and a button for "leave page".

• Tapping the current article's part of the screen, gets rid of the menu, returning the interface to full screen.
• Tapping on any of the menu options moves the scroll to the selected part and banishes the menu.
• Tapping the top of page button does what you would expect.
• Tapping the leave page (or hitting the back button again), leaves the page.

The toughest part would be writing the javascript to monitor the page for scrolling and keep a list of recently paused parts of the page.

Answer 2

I think it's abusing push state Api by pushing state every time you scroll down one page

Plus it's annoying that when I scroll down 10 pages I have to click back 10 times to go back To where I came from . In that case I would just close the window