{"id":5923,"date":"2021-05-31T02:00:00","date_gmt":"2021-05-31T00:00:00","guid":{"rendered":"https:\/\/alvarotrigo.com\/epa\/why-not-to-use-css-scroll-snap\/"},"modified":"2024-07-26T14:31:30","modified_gmt":"2024-07-26T12:31:30","slug":"why-not-to-use-css-scroll-snap","status":"publish","type":"post","link":"https:\/\/alvarotrigo.com\/blog\/why-not-to-use-css-scroll-snap\/","title":{"rendered":"Why Not to Use CSS Scroll Snap [The Hidden Truth]"},"content":{"rendered":"\n

As front end developers, we often get excited about some pretty niche things.<\/p>\n\n\n\n

Take scrolling for instance. Remember when scroll inertia<\/a> came along? We’d be excitedly flicking through websites shouting “Look! It has momentum! It has MOMENTUM!” And people are looking at us like:<\/p>\n\n\n\n

\"Katt<\/figure>\n\n\n\n

Well, CSS scroll snap is the latest innovation in the fascinating world of website scrolling. The next stage in its character arc, if you will.<\/p>\n\n\n\n

Unlike scroll inertia, which loosens up the scroll movement, CSS scroll snap reins it in. It adds more control over where and how the scrollport moves, forcing it to “snap” into place at positions you specify (by the way – the scrollport is just the element with the scollbar on it – whether that’s the window as a whole or an element within it).<\/p>\n\n\n\n

It’s AMAZING – there’s so much you can do with it. But that said, it’s not a silver bullet. There are some use cases where it’s not the ideal tool for the job, some where it can’t do the job alone (and you’ll need additional CSS\/JS), and some cases where it’s actually best avoided. Here are a few such situations…<\/p>\n\n\n

Your scroll-based animations might stop working<\/h2>\n\n\n

If you are using third-party libraries to generate animations based on the scroll position, these might stop working. This also applies to CMSs or website builders, such as Webflow, Elementor, Wix, etc.<\/p>\n\n\n\n

It all depends on how you implement CSS scroll snaps and what are your restrictions.<\/p>\n\n\n\n

The root of the problem is that, when using a CSS Snaps in full-screen and applying it on any element that is not the html<\/code> element<\/strong>, the scrolled position is no longer available in any of the following properties (as most scroll-based libraries expect):<\/p>\n\n\n\n

    \n
  • document.documentElement.scrollTop<\/code><\/li>\n\n\n\n
  • window.pageYOffset<\/code><\/li>\n\n\n\n
  • document.documentElement.clientTop<\/code><\/li>\n<\/ul>\n\n\n\n

    Instead, the value of the scroll position will now be on document.body.scrollTop<\/code>.<\/p>\n\n\n\n

    This is because the scrolling element is no longer the window<\/code> or documentElement<\/code>, but the container you chose for the snap scroll. It can be the body<\/code> itself or any other wrapper around your sections.<\/p>\n\n\n\n

    On top of that, the event listener on the window<\/code> object won’t catch the scroll<\/code> event anymore:<\/p>\n\n\n

    \/*\n* Not capturing the event when CSS snaps is \n* applied on a container.\n*\/<\/span>\nwindow<\/span>.addEventListener('scroll'<\/span>, onScroll);\n\n\/* \n* Capturing the event when CSS snaps is \n* applied on the body.\n*\/<\/span>\ndocument<\/span>.body.addEventListener('scroll'<\/span>, onScroll);\n\n\/*\n* Capturing the event when CSS snaps is\n* applied on a wrapper.\n*\/<\/span>\ndocument<\/span>.querySelector('.my-wrapper'<\/span>)\n  .addEventListener('scroll'<\/span>, onScroll);\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    This can be a bit tricky and might generate unexpected conflicts with external libraries, website builders or even with your own code.<\/p>\n\n\n\n
    Here’s a codepen illustrating the issue. Notice you won’t get any message on the JS console:<\/p>\n\n\n\n