What are the recommendations for infinite scroll?
Don't use it. It's an antipattern and an awful meme.
Infinite scroll is fine on some websites, like Reddit, Image galleries or Medium.
Pagination with rel=“next” and rel=“prev” (2011)
81–90 of 96 posts
Re: Pagination with rel=“next” and rel=“prev” (2011)
#82What are the recommendations for infinite scroll?
Like everyone else said, avoid using infinite scrolling, because it's not suitable for all types of websites. But if you still want to use it, then add a "load more" button just before footer. So, if someone want to check out footer information, he doesn't have to face the annoying infinite scrolling.
Re: Pagination with rel=“next” and rel=“prev” (2011)
#83Earlier quoted context omitted.
Safari's Reader view is one of the primary reasons why Safari's my default browser. I still use Chrome for development but 99% of browsing & reading, I do in Safari. Low power usage and the speed of Reader view is just unbeatable. It works so well and concatenates most of the paginated articles as well. If you couple it with Page One extension (it has a bunch of rules that automatically re-directs you to a single-pag…
Safari's reader view is actually a modified version of readability. At one point I believe Apple even mentioned this in some about screen or article. There are extensions/bookmarklets available for other browsers at https://www.readability.com . Personally, I've been reading long form and paginated content using the readability Send to Kindle bookmarklet which works great.
Readability's slow. It sends request to their server. I've tried every extension and addon for Chrome and Safari... and nothing beats Safari's Reader view when it comes to speed and quality of text extraction. When you hit that Command+Shift+R, it is rendered in a fraction of a second.
Re: Pagination with rel=“next” and rel=“prev” (2011)
#84[deleted]
Re: Pagination with rel=“next” and rel=“prev” (2011)
#85One of their examples is a single sentence split over three pages of an article. I'm not sure if that's just a toy example, or also a jab at the way clickbaiters game the view counts.
I would guess that whoever wrote it subtly wants to say, if web servers\apps send partial responses to requests without a Range header, then something has broken - probably somewhere between our keyboards and chairs.
Re: Pagination with rel=“next” and rel=“prev” (2011)
#86Literally one of the greatest things about the Opera browser was that you could browse an entire forum or whatever (longform article etc) with the Space key, because the browser would automatically go to the `next` page on hitting the bottom of the page. They also did some cool stuff with swiping to the next page on mobile. Opera seemed like the only browser vendor that truly championed next/prev. I only do it now as…
At least in Microsoft Edge "Next" button on the toolbar sends you to the "next" page.
Re: Pagination with rel=“next” and rel=“prev” (2011)
#87Besides making the big G happy, these semantic relationships also helps libraries authors to easily traverse a series purely on the front end. Years ago, I looked at Github's pagination API [1] and discovered this approach also makes infinite paging much easier, just send me a bunch of next pointers until there aren't any more. So I decided to support this format by default.
[1]: https://developer.github.com/guides/traversing-with-paginati...
[2]: https://github.com/backbone-paginator/backbone.paginator
Re: Pagination with rel=“next” and rel=“prev” (2011)
#88Earlier quoted context omitted.
This sounds like a really premature optimization to me. Let the DB do it's job unless you have an explain trace showing it's slow for your workload. Trying to do things like sequence columns adds complexity, when this is often handled by the engine.
OFFSET is not "handled by the engine". It heapsorts the entire dataset before you offset to a page. The top-level comment is asking for good ways to paginate. OFFSET works on localhost and with hundreds of rows. My solution is one that works in production once OFFSET fails you. For me, it was day 2.
It was day 2 for you, with the specific engine you used.
You don't need to heapsort the entire dataset before you offset to a page, and there are engines capable of doing this.
Re: Pagination with rel=“next” and rel=“prev” (2011)
#89What are the recommendations for infinite scroll?
Don't use it. It's an antipattern and an awful meme.
How about something like photos.google.com?
They have infinite(well, all history) scroll, but it is done perfectly. The scrollbar size doesn't change and you are given enough feedback to scroll directly to the part you want.
Similar is google maps. If you make it a large canvas where the missing data is paged in then it becomes quite natural.
Re: Pagination with rel=“next” and rel=“prev” (2011)
#90Also known as a good way to break many a SPA.
Single page application? Can you explain why the existence of next/prev relationships would break these? I would expect such a site to simply not use this. It's definitely nice for linearly-linked content on supporting browsers (e.g. old opera, as mentioned elwewhere in this thread).
Well, look at it this way, when creating a SPA, you're running everything in a single place. A single HTML page. In some instances, it makes sense to push the state to the query string, but often it doesn't, and more often still are the occasions developers haven't thought about it. So every time you hit the back button, and weren't where you thought you would be, that's the same issue. SPA frameworks's are getting better at that, but this still happens to me on the daily.