He’s being downvoted because suggesting cursor pagination in an example describing sorting by price (descending) is plainly wrong. While neither is bookmarkable, cursor pagination is much worse.
The UX went from “show me _almost_ the most expensive items” to “show me everything less expensive than the last item on the page I was on previously — which may be stocked out, more expensive, or heavily discounted today”. The latter isn’t something you’d bookmark.
If you believe that the user wants to see everything around a particular price point, e.g. because they've ordered their search results by price, then the correct cursor token is the price point of the top item (or the price point of the last item on the previous page, as an open bound, or even something fancier like the median price of the items in the page).
There's a choice to be made about semantics, and you have plenty of information given to you by the user in a search scenario, but ‘page 2’ is not the right choice because it has no useful semantics. If the user is hoping to bookmark the page it's because they want to preserve some property of the data for later, even in the face of data changes. I can almost guarantee that property isn't ‘items that happen to be on page 2 today’.
I cannot think of any other way to bookmark anything static unless I convert it into pdf/screenshot before sharing. Are there better ways to bookmark a list page which guarantees same list forever?
This depends on use case and who or what is actually consuming the pages. Most of the time, humans don't actually want the same list for all time (though what follows would work for them).
The only way to have a static list is to have an identifier for the state of the list at a certain time, or a field that allows you to reconstruct the list (e.g. a timestamp). This also means you need to store your items' data so the list of items can be reconstructed. Concretely, this might mean a query parameter for the list at a certain time (time=Xyz). When you paginate, either a cursor-based approach, an offset approach, or a page number approach would all work.
This is not what most human users want: they would see deleted items, wouldn't see added items, and changes to fields you might sort on wouldn't be reflected in the list ordering. But it's ideal for many automated use cases.
ETA: If you're willing to restrict users to a list of undeletable items that is always sorted, ascending, by time of item creation, you can also get by with any strategy for pagination. The last page might get new items appended, and you might get new pages, but any existing pages besides the last page won't change.
Someone said he is being downvoted for suggesting cursor-based pagination, yet one of your suggestions was the cursor-based approach, and as thus, I do not understand why he is being down-voted if it is a legitimate approach, which I believe it is.
I guess we would have to hear nebezb's solutions.
If you are already sorting by price and you bookmark at the second page (which now would be in the 3rd), what would you do? I personally do not care about the item in a sorted list enough to expect a bookmarked URL to start from there, or I cannot remember when I did and why. Any ideas why would one want this? If I bookmark second page, I know that the items on page 2 may not always be on page 2. Why would anyone expect different? If you want to bookmark an item, just go to the product itself and bookmark that. I do not think I ever bookmarked a specific page expecting that to never change.
Well, this really depends on the intention: are you looking for the cheapest items, excluding the 20 first, or are you linking to a content list.
I use Occams razor to decide this, and conceptually it is simpler to think that you are linking to a content list - so that is likely the right answer.
