Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

webmasters.googleblog.com

Post reply on HN
Print view View original

91–96 of 96 posts

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

#91

Post by gorm »

kmfrk wrote: 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…

I actually posted this link because I found pagination by relnext underused while implementing fast forward (with space support) in the Vivaldi browser.

If it's not present we start, like opera did, analyzing links, which is a little messy.

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

#92

Post by ldjb »

codedokode wrote: post #61
ldjb wrote: post #33

Earlier quoted context omitted.

There are probably things the web developer can do to minimise memory consumption, though there isn't an obvious solution. That said, the problem of losing your reading position can be solved using something like history.replaceState(). As the user scrolls, update the history entry with a reference to the current reading location. Then, when the browser restarts, the website can know where the user was previously at…

> Alternatively, I suppose cookies could be used, but that's a slightly messier solution, imo. Cookies are shared between tabs. You should use URL or builtin browser capabilities (remembering scroll position on a page) for this purpose. Infinite scroll has other UX problems. For example, you cannot see the footer of a page or cannot navigate to the items by page number. As there is no page numbers you cannot even rem…

Not necessarily. Though it's true that many implementations have these problems, they're not inherent to infinite scroll.

Regarding footers, who's to say the footer needs to go beneath the infinite scroll area? You could instead place the contents of the footer in a sidebar that stays in a fixed position. Alternatively the footer could be overlayed at the bottom of the page so it is always visible (a recent design trend would have it hide when the user scrolls down, but reappear when the user scrolls up).

As for page numbers, there's nothing stopping you from adding them. Each item should probably have some sort of permalink to allow you access it directly, and there should be suitable navigation to allow you to find individual items.

I find it quite sad that infinite scroll gets a bad rap due to poorly designed implementations. Perhaps it will get a better reputation if more websites actually put some thought into how infinite scroll is used.

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

#93

Post by username3 »

clay_to_n wrote: post #77
MichaelGG wrote: post #26

Earlier quoted context omitted.

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.

Open in new tab

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

#94

Post by mceachen »

momo-reina wrote: post #67
fbonetti wrote: post #35

Earlier quoted context omitted.

It's really easy to paginate data with SQL - just use LIMIT and OFFSET. limit = page_size offset = (current_page - 1) * limit For example, let's say you have a table with 1000 products in it, and you want to display page 3 with a page size of 50. Here's how you would write it: SELECT * FROM products LIMIT 50 OFFSET 100

I just wrote about doing it this way yesterday. http://www.mozartreina.com/

You should at least reference the fact that with MySQL, the server has to step through OFFSET result rows before it can start streaming you data. This can get surprisingly expensive, surprisingly quickly. See http://stackoverflow.com/questions/4481388/why-does-mysql-hi...

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

#95

Post by tripzilch »

detaro wrote: 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?

Because semantics. The location of the "next" page is a property of the entire page, and therefore belongs in the head (similarly, so does the title of the page). It's not a property that may be present in any of the links (or other elements) of the page.

There's a whole lot of advantages that follow, but aren't quite reasons why (e.g. like a physical book, I don't need to read the page itself to figure out where the next page is), but it follows from applying the semantics of webpage (meta) data in a consistent manner.

(except for a CYOA book)

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

#96

Post by tripzilch »

lox wrote: post #57
danneu wrote: 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.

Or they could be speaking from experience, because back in the day when webforums where the place to make online communities, as they grew beyond a certain size this sort of thing became THE bottleneck, especially for large threads.

I empirically know this was an issue back then. I also agree it's something a DB engine should handle, and I do hope that databases do a better job today.

So instead of calling out "premature optimization", maybe instead come with a practical example of a DB engine that properly handles this?

Post reply on HN