{"id":4990,"date":"2025-01-20T12:21:36","date_gmt":"2025-01-20T17:21:36","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=4990"},"modified":"2025-01-20T12:21:38","modified_gmt":"2025-01-20T17:21:38","slug":"simplify-lazy-loading-with-intersection-observers-scrollmargin","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/simplify-lazy-loading-with-intersection-observers-scrollmargin\/","title":{"rendered":"Simplify Lazy Loading With Intersection Observer\u2019s ScrollMargin"},"content":{"rendered":"\n

The Intersection Observer API<\/a> has since December 2023 in Chrome and Edge 120 been shipped with the new options<\/code> property scrollMargin<\/code>. However, its convenience seems to be understated.<\/strong> Even the MDN documentation on the Intersection Observer constructor <\/a>has yet to be updated with information about this property. It is definitely an upgrade to the Intersection Observer API, so I want to tell you more about it, particularly because it has already helped with with projects at work.<\/p>\n\n\n\n

The Problem with Intersection Observer\u2019s rootMargin<\/code><\/h2>\n\n\n\n

The Intersection Observer API is a JavaScript API that makes it possible to know whether a DOM element is in the viewport or not. An intersection observers constructor takes an options object, in which a rootMargin<\/code> can be specified. Its value is \u201ca string which specifies a set of offsets to add to the root’s bounding box when calculating intersections, effectively shrinking or growing the root <\/em>[…] The syntax is approximately the same as that for the CSS margin property\u201d <\/em>(MDN<\/a>).<\/em><\/p>\n\n\n\n

To give you an example: if you want some code to run before<\/em> the element is actually in view, rootMargin: \"25%\"<\/code> will make the Intersection Observer report an intersection when the observed element is 25% away from the viewport.<\/p>\n\n\n\n

However, a problem arises<\/strong> if the Intersection Observer:<\/p>\n\n\n\n

    \n
  1. uses the default root (the document\u2019s viewport)<\/li>\n\n\n\n
  2. is specified with a rootMargin<\/code><\/li>\n\n\n\n
  3. observes an element inside a scroll container<\/li>\n<\/ol>\n\n\n\n

    In that case, the intersection in the scroll direction is reported as if no rootMargin<\/code> has been specified. <\/strong>This makes it impossible to get an intersection before<\/em> the element in a scroll container is actually visible, which is a problem when trying to lazy load thing just before<\/strong><\/em> they are visible. <\/p>\n\n\n\n

    The workaround is to use the scroll container as the root instead of Intersection Observer\u2019s default root. But it would be convenient if it was possible to keep using the default root!<\/p>\n\n\n\n

    scrollMargin<\/code> is the New Solution<\/h2>\n\n\n\n

    The new Intersection Observer options property scrollMargin<\/code> aims to rectify this. Without it, when the root is the document viewport, the scroll containers are clipped away. This is the cause of the aforementioned problem. With the new Intersection Observer property, each scroll container is expanded by the scrollMargin<\/code> when calculating the intersection.<\/p>\n\n\n\n

    A Typical Use Case<\/h2>\n\n\n\n

    The use case for the scrollMargin<\/code> property is using it as an indicator to request data when it is about<\/em> to be scrolled into view. That’s called lazy loading, the point of which is to not<\/em> load data that is so far off screen it’s possible the user never scrolls to see it.<\/p>\n\n\n\n

    The following Pen lazy loads data both<\/em> in the vertical and horizontal directions. The UI\/UX is like a streaming service, which is exactly where my use case and thus learning of this feature comes from. Similar use cases are scrolling carousels for eCommerce, news, images, etc.<\/p>\n\n\n\n