I find that it breaks if the browser feels a need to redownload the page (e.g. if you shift-reload the page, or there's an explicit expiry in the HTTP headers that came with the HTML body) as the back-end has noted that, upon serving you the page with the 'first unread' post upon it, you have now (conceptually) now 'read' this message, and all messages up until the latest available (or page-end, should that be sooner). The next full request for "next unread in this thread" is thus served with an adjusted content (including #unread point).K-R wrote:I'm pretty sure on some forums the anchor is actually just #unread, not a specific post, which is why I thought it might break. But obviously that wouldn't apply here, since it does anchor to a particular post.
But if the browser is happy to stick with the cached source (plus the by-now-locally-cached page-realligning images and other embeddeds of various kinds), it may well render again (and near instantaneously) with identical contents as you ended up with the first time, and then shift the scrolling viewport appropriately. As described.
But, as ever, depends on all those niggling little dependencies and subtly differing behaviours as to how good or bad it is at obeying various expectations...
(I still want a forum that has user-shiftable thread bookmarks. Details follow in Spoiler, due to length...
To read such a monumental thread I have to keep a separate tab open on a "starting at page 1" cycle (at least until I get to recognisable territory/datestamps) whilst I use the unread-tagged mechanism to 'end catch-up' in my regular forum tab. Alternatives include using the browser's own bookmarking feature (remembering to remove/overwrite old ones as I add new ones) and/or pasting the relevent thread-page URIs to a text file used for that purpose.
It'd be nice to have a secondary bookmarking feature for any purpose (including the last cycle start in a Mafia thread, for instance), with a thread-top(/side) link to update this marker, perhaps to the resolution of an exact post - rather than whole page. (If I were greedy, I'd ask for multiple markings per thread, e.g. for each post with an embedded link that I want to check out later, rather than use the In New Tab or Copying To Textfile methods that I might do now, but I realise the complications to the interface that this would cause, as opposed to a single new 'special flag' per thread.) Indications, from other pages, how far back/forward this marker exists would be useful, too. But that's just afterthought.
Secondarily to this, there's the complications that wkuld need to be added in the modification of the 'next unread' marker so that alighting on page 150 of a thread, when previously the '#unread' would have been on page 120 (for e.g.), only marks p150 as (conceptually) 'read', leaving the 'first unread' linking to still aim at p120 when called upon by normal means, rather than sending it to so-far-unseen p151. It would require a single value (message# for the first unread - or probably, logistically easiest to deal with, the last read one instead) to change to a range-defining variable. Mark p150s message#s as 'read' but keep all mesages from the original starting point to the current end-of-thread as flagged unread in some suitable manner. Would also help in merged threads, where one pre-merged thread was read to a different datestamp from the other.
Realistically, this secondary concept might mean messages might need their own read-flags, as they already appear to have, but I suspect this is just a function of the thread's own (singular, at least insofar as each individual reader is concerned) "has read up to..." value.
But to combine these concepts, maybe the 'unread/read' flag ought to be click-to-toggle, or just leave that alone and add a 'marker' flag (either a second one-per-thread-per-user, thus replacing the previous marker, or per-message-per-user for unlimited numbers of 'breakpoints') with "go to [next] marked post in this thread" linky next to the thread title. And if you land on a page beyond the original 'first unread', get the chance to not reset the '#unread' point, too. I'm sure some forum backends must already have such facilities (though I've not seen them, not as I describe anyway) but none of the half-dozen or so flavours that I've used in recent times...
While I'm here, several times since I discovered by a comment on tjis thread that egosearch has been (again?) fixed I've composed a little thing about (as far as I can tell) it apparently being A-Ok for me now. Yet I didn't want to write a mere contextless "thanks" message for the fix, and clutter the place up. Nor jinx the fix by doing so. Well, I might still have jinxed it (and I note others seeing inconsistencies, still) but a little fluff down here at the end of a longer post, where no-one will even read it, avoids the contextlessness issue, methinks. Thanks!