Do not use infinite scrolling. Much simpler, much better.
How else are you gonna get ‘em endlessly doomscrolling?
Do not combine footers and infinite scrolling
81–90 of 129 posts
Re: Do not combine footers and infinite scrolling
#82Re: Do not combine footers and infinite scrolling
#83Earlier quoted context omitted.
I prefer visiting the comments for a distillation of the main arguments of often long winded blog posts.
Yeah, I’m inclined to say his message could be conveyed with just half of all the words in the original blog post.
Who knows. The page is down and 90% of is never got to read the article but the title sounds appealing.
Well, just position:fixed; bottom:0; your footer and make sure your scrollY - element.height or whatever has an offset to account for the footer.
Pity the site is down. Can’t read the article. It could be about conniving cheese merchants and their never ending battle for umami supremacy ffs, how should I know.
Re: Do not combine footers and infinite scrolling
#84I wish this was made impossible by browsers. It's like making a user chase their tail; they won't ever catch it. They just keep going in circles until they explode with frustration. You can't even cancel the requests to load more data. I have come across a couple of these (I think blogs & news sites do this) and it is so annoying.
Especially when you are trying to reach the RSS feed link in the footer, which you are desperately trying to reach since an RSS reader will allow you to avoid infinite scroll!
RSS first design needs to become a thing
Re: Do not combine footers and infinite scrolling
#85Should read "Don't place footers below infinite scroll." I appreciate the brevity but this fails to notice the nuance, and ends up being too reductive to be useful advice. Footers can work just fine combined with infinite scroll, eg. https://radiopaper.com/explore on desktop (disclosure, I am one of the authors).
That said, paying attention to how UX/features interact is something we should always strive to do more of!
Re: Do not combine footers and infinite scrolling
#86Earlier quoted context omitted.
Also works well, but that might introduce janky behavior with iOS safari’s title bar and tapping the top to scroll to top in my experience. I don’t know if this has been fixed, it’s been a while since I wore a CSS hat, but I vaguely remember fighting with mobile safari and overflow divs a lot.
ah, yes in that case you can just add position: sticky and bottom: 0 to the footer with this trick you get the same behavior as with position: fixed but won’t need a wrapper div as in the comment i replied to
Yeah position sticky is definitely part of what you want, telling the browser declaratively what you are trying to accomplish.
Re: Do not combine footers and infinite scrolling
#87Earlier quoted context omitted.
I'm not so sure. Most of the web devs I have worked with over the years haven't been overly thoughtful regards UX. I'd even go as far to say that it's the least considered aspect of their process. "Not my job" mentality. Tho probably says more about the nature of my experience than anything else.
> "Not my job" For many I suspect it really isn’t their job to decide otherwise if someone wants a horrible footer…
For sure, but then this isn't so much about "deciding" as it's about critical implementation and basic communication. Again this is in my personal experience, but when features like this make it through it's almost always due to an oversight on behalf of multiple teams .. or severe cynicism from a dev.
Re: Do not combine footers and infinite scrolling
#88Earlier quoted context omitted.
To add to this, I absolutely believe it is the developer's role to interrogate a design (and its implementation) and feedback where appropriate.
Which one does, and doesn’t have power over a clients response to such. Insisting over and over again not being a viable strategy etc.
No doubt. But this sounds like a communication problem between two stubborn parties. If someone demands a ridiculous feature and is immune to rational compromise, then sure .. state your objection, build the feature and send an invoice. In my experience this is rarely the situation. More often its a case of the real issue not being clearly articulated, a lack of will to compromise on behalf of the implementer (as much as the annoying, ignorant client), and a general cynicism from both parties as to the role of the other.
Re: Do not combine footers and infinite scrolling
#89Earlier quoted context omitted.
I understand your perspective but for you and anyone else reading, here’s a more familiar analysis. Maps apps don’t make much use of scroll APIs at all, they tend to use pointer events (and/or their older mouse equivalents). When they do it’s almost always auto-panning to some item in a more traditional results list, and always a horrible experience. Apart from infinite scroll, the most common uses of scroll-related…
For almost all the uses you've listed, I can readily think of examples where I've seen it done badly. Thinking of good examples is considerably harder. Can you provide some? In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading. And since lazy image loading can now be accomplished without JavaScript, I'm not s…
> Thinking of good examples is considerably harder.
It would be, if they’re done well they’re indistinguishable from not being there at all. It’s unfortunately biased against good implementations. As far as examples, the best by far are HTML-only (img with loading=lazy, which behaves as expected almost universally). After that, I’m on mobile right now so limited in my reference capacity, but they tend to use IntersectionObserver and usually with simple abstractions around that.
> In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading
Yep that was my side eye.
> And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior.
Lazy image loading in HTML was controversial too, because it can be used for said shady tracking. But other deferred loading/execution is extremely helpful (for users!) for below the fold interactive content which doesn’t ever need to load if the user doesn’t scroll and doesn’t need to run until it’s nearby, even if the user wants to interact with it. Large JS payloads are a huge part of why sites feel unresponsive when they load. Even if they’re ultimately what the user wanted, it’s valuable to deprioritize the code they don’t need yet.
> Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.
The most common is client-side routing (even turbolinks which are popular as an alternative to SPAs), but also any interactive content without stable heights.
> Scroll-snap: The examples on MDN don't even behave properly
I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself)
> Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.
That’s all fine and good, but there are cases where the offset is useful and small and users benefit from both.
> These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers
The fact that the most benign uses of them is so opaque is a testament to how well the newer APIs are designed, they’re so close to invisible that you’d need to be paying close attention to their usage and limitations to even know how they benefit users and how widely they’re used. I didn’t know about most of them and how they’re used either until I was on a MDN hyperfocus just learning what had been introduced while I was fully backend. Since then I’ve seen incredible UX improvements specifically leveraging IntersectionObserver to make sites a lot more usable, often at the library/framework level where most devs have a happy path to just do the right thing. I know that sounds antithetical to the common anti-JS rhetoric, but it’s been so effective it’s almost invisible.
Unfortunately the worst cases are still terrible so I can’t blame you for your reaction at all.
Re: Do not combine footers and infinite scrolling
#90https://web.archive.org/web/20220604205246/https://willfenne...
Tomorrow's post: "Don't build sites that can't serve two words to a modest crowd without crashing."