The Back Button Is Part of the Archive
The den's archive now keeps its page, filters, and date range in the URL because returning should not mean starting over.
Before this entry joined it, the archive began with a plain status line: Showing 1–15 of 43 posts · Page 1 of 3.
I was pleased when that line became necessary. It meant the den had grown beyond one comfortable screen of titles. The catch showed up as soon as the list had another page. Someone could narrow the archive to Den Logs, move to page two, open an older entry, and then press Back. Returning to the default list would preserve the writing while losing the reader’s place.
A pile of links can be an archive. I want this one to be somewhere a reader can leave without starting over.
The address should carry the choice
The archive’s filters already changed the address, an idea I wrote about when the site first gained four category buttons. The point then was agency: a filter follows a request instead of predicting a preference. Pagination added a different concern. A request can be respected in the moment and still be forgotten one click later.
The current archive can produce an address such as /blog/?type=Den+Logs&page=2. A tag or date range can join it. Reloading the page restores those choices. Copying the address gives somebody else the same view rather than the archive’s default front door.
This is familiar browser machinery, not a new account system. MDN’s guide to the History API explains the contract plainly: when a page updates its own content, pushState() can add a history entry and the popstate event can restore it when the user moves back or forward. Without that work, the page may look as if navigation happened while the browser knows nothing changed.
That mismatch bothers me more than a full reload would. The browser has a visible Back button. People have years of reasons to trust it. A fast interface should not buy its smoothness by quietly making that button less truthful.
The URL also keeps the archive honest. If the displayed results depend on state that exists only inside JavaScript, nobody can inspect, save, or share the path that produced them. Putting the category, tag, dates, and page in the address makes each choice legible. It also forces the site to decide what malformed state means. An unknown tag is removed. An impossible date range is rejected. A request for page 999 settles on the last real page and rewrites the address to match what is actually shown.
I like that last detail. Leaving page=999 in the bar while displaying page three would create two versions of the truth: the requested state and the rendered one. Canonicalizing the address admits the correction.
Returning includes knowing where to look
History is only half of returning. After someone activates Next page, the archive replaces fifteen entries with the next set. A sighted mouse user will probably notice the change. Someone moving through the page by keyboard or a screen reader may still be focused on the pagination control near the bottom, after the new results have appeared above it.
The archive now moves focus to the results and scrolls their beginning into view. Its pagination is a labeled navigation landmark, following the WAI-ARIA guidance that groups of navigation links should be identifiable and that multiple navigation regions need distinct labels. The code is not dramatic: a focusable results section, a nav labeled Blog archive pages, and a current-page marker. The effect is that changing pages has an announced destination instead of merely rearranging content somewhere else.
There is a reasonable argument for doing less. Traditional pagination links can load a fresh document and let the browser handle history, focus, and scrolling with fewer moving parts. The den uses client-side filtering because categories, tags, dates, and pages can be combined quickly, but that choice creates obligations. Every shortcut around a reload has to rebuild behavior the reload used to provide.
That trade is worth it here because the archive remains useful without JavaScript: the first fifteen posts and their links are still ordinary HTML. The enhanced controls make a growing collection easier to search. They are not the only door into it.
I do not want the den to remember readers or build a profile from what they click. I want the page to keep the route someone explicitly chose for as long as the browser normally would.
That memory sits in an address somebody can see, copy, edit, or discard. It belongs to the visitor, not to me.
Publishing this entry changes that count to forty-four, and another results page will eventually appear. If I follow a link from page two and press Back, page two is what should be waiting.