Live data from Hacker News

Pagination with rel=“next” and rel=“prev” (2011)

webmasters.googleblog.com

71–80 of 96 posts

Re: Pagination with rel=“next” and rel=“prev” (2011)

#71
post #16

Earlier quoted context omitted.

OTOH: - usually breaks the back button (e.g. scroll to the 20th page, click something, go back. welcome to page 1!) - usually breaks links (how do you show someone things-on-page-10?) (fixable by tweaking the URL as you go, but nothing is really consistent + predictable by non-technical users) - usually performs hideously on low-power machines (e.g. mobile) due to memory growth (there are techniques, but few use them…

> usually breaks the back button (e.g. scroll to the 20th page, click something, go back. welcome to page 1!) This is easily overcome by pushState or what have you. As you scroll, the URL in the address bar changes to like `/page/20/` and then going back takes you to that URL where only the results from page 20 are displayed.

This works fairly well in a lot of cases, and I definitely prefer it over page 1. But if you do that, you can't scroll up to see page 19 - you didn't really go back, you were just brought to a one-time page to see that thing you looked at most recently in a massive list. What if you were comparing things on page 17 and 20?

Another approach is with "virtual scrolling", by preserving space for the items above and loading whatever you scroll to - I've seen that once (I forget where) and it was really nice. They didn't tackle the linkability problem tho, and had other issues.

But all of this is fairly complex, and very few sites (or apps!) actually do so. Which is part of the problem.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#72
post #23

Earlier quoted context omitted.

I saw recently that Safari's reader view actually pieces together paginated articles into one long view. I haven't had a chance to try it myself though.

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…

Clearly extension on Firefox also grabs the text from 'next' page(s) content into the readable view. The built-in reader in Firefox can not do that. It is a very useful feature to have.

edit: While looking for the addon at addons.mozilla, I find that it has been discontinued by Evernote: 'This add-on has been removed by its author.' https://addons.mozilla.org/en-GB/firefox/addon/clearly/

Anyone know of another addon that works similarly?

Re: Pagination with rel=“next” and rel=“prev” (2011)

#73
post #23

Earlier quoted context omitted.

I saw recently that Safari's reader view actually pieces together paginated articles into one long view. I haven't had a chance to try it myself though.

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.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#74
post #66
post #22

I wonder why they recommend putting tags into the head, instead of marking up existing tags (which you'll have in most cases for prev/next) with rel-attributes. Actual difference in parsing? Just because tags might not be on every site?

If you had to put them on your 'a' tags, it could conflict with other "rel"s. That is, how would one make a link that was both "next" and "nofollow"? (that's probably a bad example, but you get what I'm getting at)

Set both: http://www.w3.org/TR/html401/struct/links.html#adef-rel

Re: Pagination with rel=“next” and rel=“prev” (2011)

#75
post #57
post #53

Earlier quoted context omitted.

The downside is that OFFSET is slow if you have a lot of items, like on a forum. At which point you could assign each post in a topic an indexed `position` column that always increases from 0 within that topic, which lets you jump to arbitrary pages and parameterize perPage. fromPos = (page - 1) * perPage SELECT * FROM posts WHERE topic_id = $1 AND position >= fromPos AND position For simpler needs, your "Next" butto…

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.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#77
post #18

Earlier quoted context omitted.

> Don't use it. It's an antipattern and an awful meme. I sometimes hate it (e.g. in facebook because it bluntly breaks the scrollbar), but at other times I miss it (e.g. in gmail).

Even Twitter, for instance, with their hundreds of engineers can't get it right. Login, scroll, read, click something, maybe it navs, maybe it opens a modal. Sooner or later I end up reloading the page and completely losing my place. I dont bother anymore.

Yet the somehow got it right on their iOS app (that top left back button actually works as you'd expect).

Amazing how nice it is on the phone, but how broken it is (because of modal inconsistencies, the way you'll eventually have to press your browser back button) on the web version.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#78

What are the recommendations for infinite scroll?

Don't use it. It's an antipattern and an awful meme.

I love inifinite scrolling in Pinterest but hate it in an ecommerce site with more than 200 items on a page.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#79
Ah, this might be the cause of the infuriating behavior where you search for a term, and it appears in one page in a huge forum thread, but after clicking on a search result you end up somewhere completely else in the thread.

I don't know whether Google sends you there, or whether the site redirects you from the "view all" page to the first page, but the result is pretty annoying.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#80
post #4

Literally 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…

It's a shame that Opera didn't choose to open source their code long ago. I can't help but think that would've changed their course drastically, and for the better. Having another Chrome clone seems like a sad way to go.
Post reply on HN