When you click on a “unread post” icon to open it in a new page it should change to a “read post” icon.
I tend to open the “latest posts” thing then go down the list middle button clicking the icons to open them in a new tab. Would be nice to have the list update to show what has been read tho.
The JS is trivial, made needlessly complicated due to buddy press’ appalling css.
I have a couple of UI issues with this:
this change would assume the page has loaded correctly, which it may not, and;
without a refresh, there is no way of knowing if an addition post has been made since you loaded the page, so the read icon will be incorrect;
For these reasons I don’t think this functionality should be added, however, all is not lost, as you could pretty easily add this functionality for yourself using Greasemonkey or Tampermonkey =)
My concern is that without polling, or pushing data to the client, a user has the certainty that: at the time of loading, the page is ‘correct’ (the server and client are in sync), and it is understood that things may have changed since that point in time.
JS changes to the page of this nature are performed purely client side, where as fetch request is made on the server; in this case, the JS has no way of knowing if this request has been made after the click event has been dispatched (and the icon changed), so it does differ from a refresh.
The page is correct at the time of loading. Making client side changes like this will remove that assurance.
It’s no different from the web browser turning a link a different colour if you’ve followed it.
Whether the page was correct at a point in time or not is irrelevant. At any point after that time it has the chance to be incorrect. This change makes it more likely to be correct (since at the moment we know its absolutely incorrect as you just followed the link). We’ve gone from 100% wrong to 99.99% right. And you really think that’s not an improvement?
The thread became fully read when you followed the link. That’s exactly the same as if you hit refresh after following the link, only the status of other threads may be different.
It is different, web browsers change a link to a :visited state only when the page has been partially or fully loaded, depending on the UA implementation, not when the click even has occurred… if the page is not returned correctly, the link does not change… all this is dependant on the UA of course as this is not explicitly covered by the HTML spec.
It’s not irrelevant, in fact it’s the key to this entire discussion, “the page was correct at a point in time” is the only certainty that can be safely relied upon. It’s clearly understood that for a “normal webpage” (not an asynchronous web app), the page is a representation of a snapshot in time , when it was loaded, thus in sync and correct, after which it is never incorrect as it is representative of the time it was served. As soon as any part of the page is changed client side after that, the “at a point in time” certainty is removed, thus any and all data on that page is potentially ‘incorrect’. We’ve gone from 100% correct to 100% uncertain, to me that is a massive step backwards.
I fear we are getting a tad too technical about all this, I listed my reasons in the beginning why I don’t think this should be done, and I think the good old refresh is the most reliable overall solution… that is just my opinion. I still think you should Greasemonkey it up so you can have the functionality you desire right now without delay.