Hacker News Reader

Comment by alpaca128 | Hacker News Reader

Not to mention one misclick that brings you to a different page will instantly make you lose all scrolling "progress", on some fast-paced websites without a chance to find the original position again.

View on HN

Even in some case scrolling back to the top makes you lose the progress. And that happens automatically when you do a Ctr-F and start typing, the matching of the first character you type will likely be at the top of the page.

Even worse is how infinite scrolling breaks Ctrl-F searching. Most websites no longer render the offscreen content to improve performance, so the content you scrolled past (and the content you haven't gotten to yet) is no longer there for searching.

That's probably just a poor implementation on those websites. I thought the ability to search across larger content using Ctrl-F is one of the major advantages of infinite scrolling over traditional pagination.

> Most websites no longer render the offscreen content to improve performance

Which may now be obsolete. Over the last year firefox has implemented some amazing flexbox layout computation improvements that make appending to a flexbox with many elements (>5k) stay fast. It only re-computes the changed ones.

Of course you need to do some profiling to check that you don't accidentally deviate from the happy path by introducing changes that touch all elements.

> Most websites no longer render the offscreen content to improve performance

I noticed when trying to screenshot a Twitter thread in Firefox that twitter does this, on the mobile site at least.

You can still implement this by updating the URL dynamically as you pass the (invisible) page delimiter. I’ve seen infinite scrolling news sites implement this.

Yup. And you can implement something that loads all the content up until that point when the user presses F5 in the middle of the page. And you can implement smooth scrolling that takes into account your sticky header. And you can make your pagination based on the ID of the last seen page item instead of based on count.

The question is, is this the best use of your time? Are you willing to invest more time in it when you give it to the user? Because the user will do something you haven't thought of, they will break it, and you will need to fix it.

You can, but that means if a user scrolls through a page and decides to share it by copying the URL they'll get a link to the page they've just scrolled in to rather than the one they've just read which is very likely to be wrong. It's something that makes me much less likely to share links.

To be fair, this only happens due to programming bugs on the website. You can easily store the scroll position in the HTML5 pushstate API. The big websites like Twitter and Facebook get this right.

Famously, imgur gets it wrong. After 10 images you can click "load more images" to see the rest of the album, but when you return to the album you have to click it again.

Imgur does lots of things wrong, it's really really horrible to use, especially on mobile.

Although to be "fair", that's probably largely intentional crippling of the site to push users towards their app.

I just tried Twitter on my iPhone and it fails as described if I manually put in a new URL and then go back from there. Google gets it wrong in their search results. When it’s that common to have this bug I’d say it’s fair to just consider it to be part of the technique.

Facebook does not get this right. I end up in a random place with content I haven’t seen is the back button all the time. It’s one of the things I hate most about the UI.

Reply on news.ycombinator.com