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

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.

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

of course it is allowed to put it in <link>. And if your badly sanitized HTML (which hopefully did strip the malicious onClick handler ;)) includes an <a rel="" href="">, are we sure that parsers will prefer the <link> in the header? Or will Google and others actively ignore the <a>, 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 <head> might be good, but a search engine and a browser both have to parse the entire page anyways...

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 < fromPos + perPage
    ORDER BY id

    <ul>
      {% for item in items %}
        <li>{{ item }}</li>
      {% endfor %}
    </ul>

    <a href="/items?afterId={{ items[items.length - 1].id }}">Next</a>

    SELECT *
    FROM items
    WHERE id > $afterId
    LIMIT $perPage

http://www.mozartreina.com/

Yes, don't unnecessarily break up content. But most pages are going to include lists of some sort that you want to be paginated in some way.

If you look at HNs /new queue, there are submission IDs in the next links, so you can click "more" multiple times without seeing content multiple times, even if new submissions have pushed them down in the global list by now. Useful if there are many updates and new entries come in at the "top" of the list.

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

Similar is google maps. If you make it a large canvas where the missing data is paged in then it becomes quite natural.

Salient points seem to be:

# Update URL during scrolling so links don't break, and link to the "deep" item not just the first page.

# Don't break history, so back/forward/reload buttons act as would be expected.

# Truly endless scrolling kills browsers due to consuming increasing resources, so don't do it. Seems that a compromise might be: larger page sizes that lazy-load content up to a sensible max length. For example, in a data set of 1,000 results perhaps display the first 10 immediately and lazy-load up to 50 during scrolling. Then normal paging occurs. (Max items per page could be user-selected, as is currently seen sometimes.) Items that have scrolled off the top of the page could be removed from the DOM too, and lazily reloaded on demand.

# Endless scrolling is not always appropriate, but there may be appropriate use cases. It would be good to identify these cases, perhaps through user testing.

# Obviously, it shouldn't break screen readers or text-only browsers etc. These should be handled gracefully.... which raises the question of how to effectively navigate through a large list, possibly of unknowable length, in these browsers.

I feel sure I've seen various of these, but not all together in one implementation. Anyone seen somewhere that does all this well?

Any further suggestions/criticisms of this pattern?