Hacker News new | past | comments | ask | show | jobs | submit login

Losing the hashbang and instead using history.pushState() to update the URL won't solve the problems that infinite scroll introduced.

Also, the idea of using a page range (e.g. /pages/1-3/) will only preserve which "pages" were loaded when you pass on the URL. It does not state which "page" you actually want to link to. This solves a problem that no one had - I don't care how many pages you had loaded in your browser when you pass me a link.

Here's a slightly different approach to infinite scroll that, imho, works reasonably well: (NSFW) http://www.pr0gramm.com/




If that's your concern, than you should provide fragments (as they are intended to use) within the list of 30 posts i.e:

http://example.com/pages/1-3#2011-05-12-screw_hashbangs_buil...

Otherwise your argument doesn't make much sense, linking to a list of 10 blog posts instead of 30 still doesn't show the user which specific post you wanted to link to out of a list of posts. Infinite scroll neither makes this problem worse nor better.


I think you have different problems with infinite scrolling to the one the author has solved. For the end user, almost all infinite scrolling implementations break the back button completely, and those that don't have horrid usability issues - this is the first one I've seen that just works.

The page you linked to doesn't avoid this issue entirely - when you click back your browser will initially load just the first page and use Javascript to load the content you were looking at last.

I'd never considered the issue of passing on a link, but there is no reason the author's implementation couldn't also add a # to the URL to indicate that in addition to their current method, solving both problems. So for example, if you scrolled to page 3, and then back up to 2, and wanted to share that state with me the url would be /pages/1-3/#page2 or similar.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: