Pagination with rel=“next” and rel=“prev” | Hacker News Reader

Pagination with rel=“next” and rel=“prev”

googlewebmastercentral.blogspot.com

122 pointsbarredo31 comments

I haven't thought about rel="next" and rel="prev" since the middle of the last decade, but I recall that the blogging community used these attributes in semantically different way. Instead of marking parts of a single unit of content, rel="next" and rel="prev" were used to mark the next document in a chronological series.

IMO, this latter usage is consistent with both HTML 4 and HTML5 semantics. I suppose Google's approach can be read as consistent with the specs, too, but either usage takes a different interpretation of "a document" and the relationships in a series of documents.

http://www.w3.org/TR/html401/types.html#type-links

http://dev.w3.org/html5/spec/Overview.html#sequential-link-t...

I agree with you, the HTML 4.01 specification says that "next" refers to the next document in a linear sequence of documents. A sequence of documents ordered chronologically would be a linear sequence, like the sequence of blog articles published on a certain blog. The individual articles could be regarded as "stand alone" documents and do not require the other articles in the sequence for some "completeness".

The Google article talks mainly about paginated content and mentions that it comes in different forms. The examples given in the article suggest that here we have a sequence of pages where we should or could have only one document, like in the example of the forum thread: it may consist of many pages, ordered in a linear fashion, but individual pages of the thread might be somehow incomplete. The whole thread is the document. I think that this interpretation is different from the interpretation of next/prev indicating a chronologically ordered sequence.

The article mentions also "The first page":

>>The first page only contains rel=”next” and no rel=”prev” markup.<<

"The first page" means that there is only one. Could we have more than one first page as entry point into the sequence? Like a story with different possible beginnings converging to a common end?

You can certainly have multiple entry points, although you can't then statically model it with just prev in a simple manner.

Is this just a matter of the definitions of "page" and "document"? I haven't read the specification, but I wouldn't be surprised if it called webpages "documents".

An interesting aspect is if Google's treatment of these links incentivizes publishers to add them, then browsers (or browser extensions) will also be able to use them to defeat the purpose of pagination in the first place, e.g. by having something like Readability slurp all the pages into a view-all page.

Although the linked article on view all pages http://googlewebmastercentral.blogspot.com/2011/09/view-all-... says they are going to try to make search results point at unpaginated content as thats what users want...

Well, not just that. I imagine browsers implementing keyboard shortcuts that automatically go to the next or previous pages.

I've used the "Link Widgets" plugin for Firefox, which does a very good job of guessing and setting alt+pgup/pgdn to forward and back.

I've been hoping for this for many years. Without requiring new buttons or keys, an interesting strategy would be to make the "history forward" gesture/key/button follow the "next" link. Assuming sane use of next and previous this works well for viewers that start at the beginning. What to do for the "back" function is ambiguous when previous doesn't match to history, as in a case where a viewer lePt Ito the middle of content via a search.

Opera has that already — Forward button becomes "Fast Forward" and if you use Spacebar to scroll to the bottom, it will automatically follow "next" link.

Ironically, HTML5 recently dropped bunch of link relationships because of lack of browser and search engine support.

The pentadactyl add-on (used to be vimperator) for FF does this, ]] for next, [[ for previous. I believe it first checks for 'rel=' links, then links that contain 'prev', 'back', '<<' or similar snippets.

Hopefully this catches on, and we can use this instead of every site trying to have its own keyboard shortcuts (j/k or left/right or z/x/c, that last one being especially stupid for non-qwerty typists).

I use this in Conkeror, and it drives me batty when I stumble on comics that don't provide pagination links. This kind of stuff should be Web 101.

I'd love to be able to swipe left or right to navigate pages on a tablet.

Yup, on Chrome it seems that Alt-N goes to the next page and Alt-P goes to the previous one. I really wish more web sites supported it, though.

They did: https://bugzilla.mozilla.org/show_bug.cgi?id=87428 it got removed at some point, but there used to be a toolbar with various link elements, prev, next, alternate version, etc.

For probably five or six years now, OmniWeb (for Mac) has had a feature that scanned the page for something that looked like a "next" link, and chooses it if you press Enter (a distinct key from Return on Mac keyboards). Very useful for browsing multi-page documents and for crawling webcomic archives.

AutoPager for Firefox already does this, but I think it needs to use heuristics or hard-coded rules for most sites: https://addons.mozilla.org/en-US/firefox/addon/autopager/

And Firefox will pre-fetch links with rel="next" so that they load faster: https://developer.mozilla.org/en/Link_prefetching_FAQ

Safari (which leverages Readability for its Reader functionality) also does that. It seems to try and detect links at the end of an article that look like pagination links which sometimes leads to interesting failures. Being able to do that more reliable for more websites would definitely be a plus.

Google continues to leverage its power to provide a better experience for their users as they click on links they find through search. This is one example, and First Click Free is another.

The flip side of this is that publishers are now offering an inferior experience to users who navigate directly to their sites. If I type in NYTimes.com and start browsing through articles because I'm a big fan of The New York Times, I'm treated worse (I have to deal with an article limit and pagination) than if I stumble on their articles through Google. Google is giving more and more value to brands, while creating an atmosphere that rewards people who have no brand loyalty (except to Google).

Google has been strong-arming publishers for a long time. Generally it has made the Internet a better place, but it still makes me nervous (especially as a publisher). Google seems to be pushing to eliminate more and more tactics that are profitable for publishers (and generally bad for users). I doubt that Google will kill the goose that laid the golden egg, but you have to think that publishers are going to start to push back if it goes much further.

Making the search experience better for their users by utilizing a feature the website provides (full page view versus pagination) is not strong arming publishers. The websites already give that same experience option, Google is just attempting to make the web a smarter place. What's wrong with that?

They could be utilizing their search dominance to do a lot more harm than good. However, almost everything they do helps make the web better, even if it does push their bottom line. That's business.

Most businesses don't care about your loyalty to other brands. Why should they? Google, on the other hand, has made a lot of strides toward giving big brands benefits in the search results. I'm not sure whether this is good or bad, but saying they reward people who have no brand loyalty is untrue.

i implemented these on a site a while back after an opera user requested it, because apparently opera has a keyboard shortcut or something to automatically go to the next/previous pages that use these tags.

what i found was that opera started doing a pre-fetch on them as soon as i added the tags, so every time an opera user would visit the site, they would fetch two pages. i had to remove the tags to cut down on the resource usage.

What was your percentage of Opera users, if you don't mind me asking? If it's only a very small percentage, was the increase in resource usage really that significant?

it was a small percentage, but the pages being requested were accessing external resources that i had to pay for on a per-view basis. paying for those views without actually showing anything to the user was wasteful.

I use both Opera and rel=next on my websites and never noticed it prefetching anything (but I wish Opera supported at least rel=prefetch…).

There used to be proxies (Google Web Accelerator http://webaccelerator.google.com/support.html#basics2) that aggresively prefetched pages, but modern browsers don't prefetch unless you explicitly ask with rel=prefetch (or Chrome's own version of thereof).

Is there a good reason to paginate anything these days? The fact that publishers make people click on a 12pt link to read the next "page", and thus view more ads, is pretty insane.

If you aren't using infinite scrolling, chances are you're doing it wrong.

Web comics, documentation, anything where clicking 'back' should get you to the position you were browsing last without waiting for an ajax call, etc. These all benefit from pagination.

Another plus with adding rel="next" and rel="prev" is that you can easily add keyboard navigation to your pages with a script like this: http://vemod.net/rel-keyboard-navigation

will_paginate has been using these attributes for quite a while.

Great, this will just encourage pagination in online articles.

It's not as if lack of support stopped pagination. I'd prefer better search.

I don't think this will make any dent in the use or expansion of pagination. Pagination in order to increase ad impressions have already done the most damage.

Reply on news.ycombinator.com