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

31–40 of 96 posts

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

#31

Post by Guest91283 »

kmfrk wrote: post #14
ajkjk wrote: post #11

Earlier quoted context omitted.

Why's that?

It is extremely rare that it doesn't bring my browser to its knees after a certain amount of scrolling. (This is with 12 GB on Chrome.) You will also end up losing your reading position after a browser restart or on iOS where Mobile Safari reloads a page to save memory. It's a dumb, pointless feature that at the very least shouldn't be the default option. I'm sure there are hypothetical scenarios that may or may not…

I don't understand why more sites don't just use pagination with larger result sets. Return pages with 100 or 200 results each. It takes a little more bandwidth, but it's a good middle ground between pagination and infinite scroll.

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

#33

Post by ldjb »

kmfrk wrote: post #14
ajkjk wrote: post #11

Earlier quoted context omitted.

Why's that?

It is extremely rare that it doesn't bring my browser to its knees after a certain amount of scrolling. (This is with 12 GB on Chrome.) You will also end up losing your reading position after a browser restart or on iOS where Mobile Safari reloads a page to save memory. It's a dumb, pointless feature that at the very least shouldn't be the default option. I'm sure there are hypothetical scenarios that may or may not…

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 and can return them to that location. This is the approach Discourse uses [1]. Alternatively, I suppose cookies could be used, but that's a slightly messier solution, imo.

Unfortunately, I haven't seen many websites adopt such a feature. Which is a shame because infinite scroll can make for a great user experience -- if done right. But too many websites actually suffer as a result of poorly implemented infinite scroll.

[1] https://eviltrout.com/2013/02/16/infinite-scrolling-that-wor...

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

#34

Post by kmfrk »

Guest91283 wrote: post #31
kmfrk wrote: post #14

Earlier quoted context omitted.

It is extremely rare that it doesn't bring my browser to its knees after a certain amount of scrolling. (This is with 12 GB on Chrome.) You will also end up losing your reading position after a browser restart or on iOS where Mobile Safari reloads a page to save memory. It's a dumb, pointless feature that at the very least shouldn't be the default option. I'm sure there are hypothetical scenarios that may or may not…

I don't understand why more sites don't just use pagination with larger result sets. Return pages with 100 or 200 results each. It takes a little more bandwidth, but it's a good middle ground between pagination and infinite scroll.

Not to mention that people still use that one terrible loading-animation icon that looks like crap, because they didn't configure the CSS properties correctly.[^1]

[^1]: https://jsfiddle.net/76FSM/17/

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

#35

Post by fbonetti »

kevindeasis wrote: post #19

How do you guys implement / What's the best practice for paginating your db using sql and nosql? I know there are a bunch of gotcha's to look out for

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

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

#36

Post by toupeira »

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…

Which is why I love the Space Next addon for Firefox (https://addons.mozilla.org/en-US/firefox/addon/space-next/)

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

#37

Post by detaro »

ldjb wrote: post #27
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?

Well, for one thing, it's in the HTML standard [1]. But also consider websites such as forums that allow users to post custom HTML to a page. Although there is often some sanitisation, that often doesn't stretch to removing attributes from tags. In those cases, it might be possible for a user to hijack the sequential links and make them point to some other website. [1] https://www.w3.org/TR/html/links.html#sequential…

your link says:

The next keyword may be used with link, a, and area elements

of course it is allowed to put it in . And if your badly sanitized HTML (which hopefully did strip the malicious onClick handler ;)) includes an , are we sure that parsers will prefer the in the header? Or will Google and others actively ignore the , despite the standard allowing it on both? That would be useful to know.

For simple bots putting it in an easy-to-discover link in might be good, but a search engine and a browser both have to parse the entire page anyways...

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

#38

Post by err4nt »

ldjb wrote: post #30
kevindeasis wrote: post #19

How do you guys implement / What's the best practice for paginating your db using sql and nosql? I know there are a bunch of gotcha's to look out for

I feel there are essentially two approaches. You could store the entire article text as a single chunk of data. The text would be marked-up to indicate where the page breaks are. Each time a page of the article is requested, the entire article is fetched from the database, but the website software extracts only the necessary extract. This is rather inefficient in principle, although it is possible to optimise, and it…

I'm no DB programmer, but despite the inefficiencies of the first approach (fetch entire article each time and display a different chunk) it would allow for users (or admins) to change page length after the article is written a LOT more easily than if each page was stored separately. Is this a potential concern of using the second method where each chunk is in its own field?

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

#39

Post by pmarreck »

fbonetti wrote: post #35
kevindeasis wrote: post #19

How do you guys implement / What's the best practice for paginating your db using sql and nosql? I know there are a bunch of gotcha's to look out for

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

And if the data frequently changes during pagination?

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

#40

Post by tantalor »

kevindeasis wrote: post #19

How do you guys implement / What's the best practice for paginating your db using sql and nosql? I know there are a bunch of gotcha's to look out for

One great approach is cursors. Basically, you keep track of the value of the sort function (e.g., relevance) of the last record on the page, and add that to your filter (e.g., WHERE relevance > $LAST_RELEVANCE) to get the next page.

This is very efficient when your table is indexed by that field; you can seek directly to the next record.

Some database APIs do this for you!

I wrote up my experience implementing this on App Engine here, http://johntantalo.com/blog/paginating-with-bookmarks-in-app...

Post reply on HN