This just looks like bad UI to me.
On my desktop browser I often press End to get somewhere near the end of the page, here if you do that it just goes back up.
If I accidentally scroll to the end while reading something I can't scroll back up, I'll have to scroll down to the end and hope I don't scroll too far and trigger the loop again.
What's even more annoying are sites like Quartz, where if you scroll to the bottom it will load some additional headlines. When you scroll past these, more are loaded. It's a page without an end.
The ultra annoying thing is that in Safari Reading List, scrolling "past the end" of a page takes you to the next item in your Reading List. So Quartz breaks that feature...
I tried viewing the Look Studios website on Firefox, scrolling down with the touchpad. The website skips over some content sections and once I get to the page footer, the page suddenly scrolls extremely slowly. To the point where it looks like my browser crashes every time I reach the bottom of the page.
Indeed, the website seem fairly broken. i.e. the right side is clipped as well on Firefox (can't see the Contact link on the mast head).
On (desktop) Safari hovering over a few sections causes the site to just randomly scroll to another section (e.g. Hovering any of the first 2 links of "Get in touch" goes a section back and the third one goes to the last hero section").
In mobile Safari (latest version) the website stops functioning after the first scroll until the end, the hero is the only thing that is viewable.
Lastly, the infinite scrolling loop doesn't work backwards (i.e. scrolling up) which gets a bit confusing.
There's something extremely fundamental in scrolling, it gets embedded in the user's cognition. I wonder what we need to do to raise awareness in finally stopping to meddle with it.
Furthermore, it loads a bunch of multi-megabyte png's that it doesn't even display, adding up to a page load of 17 Mb. I wouldn't be surprised if it loads these images on mobile too, but I can't be bothered to check.
I'm continuously baffled by how many of these agencies/studios have incredibly shitty websites.
After messing about with the Look studio page, I learned that they have a "force scroll to next session" bound to clicking. As it turns out, when using two finger scroll I frequently click, causing the page to leap around like you described.
I tried the live demo on Safari on iPhone. When it arrives to the end (with the logo) it's starts flickering around 10 times. Then you can continue scrolling.
I don't know if it's on purpose (distracting effect while doing your stuff). But it's more looking like a bug.
This is due to the fact that on mobile devices the scroll event is triggered when you've released your finger. Unlike web which is during the scroll. I am working on a fix for this now!
Are there implementations of infinite scrolling that delete DOM elements outside of a specified range of the viewport? Then the scrolling still appears responsive to within X pages of scrolling from the current viewport, but any pages beyond that range are actually inserted in on demand when the viewport moves towards them, saving browser memory at the cost of bandwidth and computational time on both the browser and server sides.
I've investigated the problem on a VueJS app which rendered a live-updated table-like DOM with thousands of rows, and was quite slow in rendering and scrolling, especially on mobile. For my use case the easiest solution was to render the first X elements, on-the-fly render the next elements as you scrolled down and disable the VueJS watching and reactivity logic for the DOM elements outside the viewport, so that when you scroll back up the elements are still there and you do not spend too much time recreating them (the DOM is slow).
I had to use unexported, private VueJS methods, I raised an issue on Github asking them to provide public hooks but it was declined.
This method works when you have a big but not huge list. In the latter case the bottleneck is not your JS framework but the browser, so yeah, you should delete and create DOM elements on the fly.
(I'd share my code but it's on a commercial app, and a huge hack that I'm surprised I've managed to make work.)
For the GP, the technique itself is older [4][5][6][7], but with this new crop of component-oriented frameworks I can see the value of a dedicated component.
Awesome, thank you, that looks like what I'm asking about, I'll check it out. If I have a straight table, I tend to reach for SlickGrid, but for more free-formatted content, this looks much more useful.
>> Are there implementations of infinite scrolling that delete DOM elements outside of a specified range of the viewport?
Yes, and these are the only implementations anyone should ever use. You have to remove the DOM elements for rows above and below the viewport (+/- headroom for a couple of rows). When you do so, you use only two placeholder elements to replace the scrollable height of the removed items (one above the viewport, one below).
Any other solution breaks scrolling expectations and/or uses too much memory, which will crash mobile browsers (particularly on iOS). An infinite scroll library is not a 1-day project. It takes a lot of mindful effort to do properly, and nearly every library author takes shortcuts that don't take these requirements into account on their first release.
Not debouncing the scroll action seems like a pretty poor idea. This could use some optimization for sure. Also, not hugely important, but my OCD hates that the source code has several misspellings and inconsistent use of const/var/let. A little confused why you're using useCapture = true in the addEventListener call. Neat CSS, I learned a couple things.
Exactly! This was just a little experiment we tried out on our site, a lot of people liked it so I made a little release of how it works, I understand it's not for everyone. We just had the idea and wanted to put it to the test... Thanks for the feedback everyone! ️
Thanks for the feedback. Thats good to know, I know with ios it stops DOM manipulation until after the scroll event has been finished, hence why we're getting the flashing issue. I can fix this by taking away the -webkit-overflow-scrolling: touch; issue is then the scrolling isn't smooth.
If I accidentally scroll to the end while reading something I can't scroll back up, I'll have to scroll down to the end and hope I don't scroll too far and trigger the loop again.