Live data from Hacker News

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

webmasters.googleblog.com

21–30 of 96 posts

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

#21
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…

Yeah, this article reminded me about that feature. Used to use it all the time.

Fewer webpages where this would be useful now for me. Most either have infinite scroll, or forums/comments are in a complex tree-structure instead of pages.

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

#23
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 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-page view of articles), 99% of the sites will be a single page in Reader view.

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

#24
post #21
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…

Yeah, this article reminded me about that feature. Used to use it all the time. Fewer webpages where this would be useful now for me. Most either have infinite scroll, or forums/comments are in a complex tree-structure instead of pages.

Many forums haven't gone anywhere. By forums I mean what some refer to as bulletin boards.

Neither are blogs. Granted, Medium is making a complete mess of the semantic web, but all the more reason for them to support a semantic standard that might guide hapless readers such as myself to find their way.

For the most part, the "change" that "obviates" the standard are developers writing shitty code with all kinds of JavaScript nonsense that wreak havoc on accessibility, load, and UX. It's a little like saying right-clicking and using the back button in the browser aren't needed anymore, because dumb new frameworks are breaking them. :)

Dear lord, I just remembered Twitter's hashbang urls. To this day, they still break my Pinboard bookmarks.

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

#26
post #18

Earlier quoted context omitted.

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

> 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.

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

#27
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-link-types

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

#28
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…

The feature is available in some browser extensions as well. Vimium, for instance, has that available with ]]

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

#29
post #12

Also 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).

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

#30

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 does keep things relatively simple.

On the other hand, you could have an "articles" table and a "pages" table with the relationship:

  articles 1  1..* pages
Each page's text is stored as a separate row in the "pages" table, along with the article ID and a page number. When a page is requested, only the page that matches the requested article's ID and the appropriate page number. The database schema here is more complex, but is likely to be more efficient.
Post reply on HN