Michelle Barker appears as one of a heavenly host, coming forth with scroll in hand to pronounce an end to janky scrolljacking! Unto us a new specification is born, in the city of TimBL, and its name shall be called Scroll Snap.
One area where the web has traditionally lagged behind native platforms is the perceived “slickness” of the app experience. In part, this perception comes from the way the UI responds to user interactions – including the act of scrolling through content.
Faced with the limitations of the web platform, developers frequently reach for JavaScript libraries and frameworks to alter the experience of scrolling a web page – sometimes called “scroll-jacking” – not always a good thing if implemented without due consideration of the user experience. More libraries can also lead to page bloat, and drag down a site’s performance. But with the relatively new CSS Scroll Snap specification, we have the ability to control the scrolling behaviour of a web page (to a degree) using web standards – without resorting to heavy libraries. Let’s take a look at how.
Scroll Snap
A user can control the scroll position of a web page in a number of ways, such as using a mouse, touch gesture or arrow keys. In contrast to a linear scrolling experience, where the rate of scroll reflects the rate of the controller, the Scroll Snap specification enables a web page to snap to specific points as the user scrolls. For this, we need a fixed-height element to act as the scroll container, and the direct children of that element will determine the snap points. To demonstrate this, here is some example HTML, which consists of a <div> containing four <section> elements:
<div class="scroll-container">
<section>
<h2>Section 1</h2>
</section>
<section>
<h2>Section 2</h2>
</section>
<section>
<h2>Section 3</h2>
</section>
<section>
<h2>Section 4</h2>
</section>
</div>Scroll snapping requires the presence of two main CSS properties: scroll-snap-type and scroll-snap-align. scroll-snap-type applies to the scroll container element, and takes two keyword values. It tells the browser:
- The direction to snap
- Whether snapping is mandatory
scroll-snap-align is applied to the child elements – in this case our <section>s.
We also need to set a fixed height on the scroll container, and set the relevant overflow property to scroll.
.scroll-container {
height: 100vh;
overflow-y: scroll;
scroll-snap-type: y mandatory;
}
section {
height: 100vh;
scroll-snap-align: center;
}In the above example, I’m setting the direction in the scroll-snap-type property to y to specify vertical snapping. The second value specifies that snapping is mandatory. This means that when the user stops scrolling their scroll position will always snap to the nearest snap point. The alternative value is proximity, which determines that the user’s scroll position will be snapped only if they stop scrolling in the proximity of a snap point. (It’s down to the browser to determine what it considers to be the proximity threshold.)
If you have content of indeterminate length, which might feasibly be larger than the height of the scroll container (in this case 100vh), then using a value of mandatory can cause some content to be hidden above or below the visible area, so is not recommended. But if you know that your content will always fit within the viewport, then mandatory can produce a more consistent user experience.
See the Pen Simple scroll-snap example by Michelle Barker (@michellebarker) on CodePen.
In this example I’m setting both the scroll container and each of the sections to a height of 100vh, which affects the scroll experience of the entire web page. But scroll snapping can also be implemented on smaller components too. Setting scroll snapping on the x-axis (or inline axis) can produce something like a carousel effect.
In this demo, you can scroll horizontally scroll through the sections:
The Intersection Observer API
By implementing the CSS above, our web page already has a more native-like feel to it. To improve upon this further we could add some scroll-based transitions and animations. We’ll need to employ a bit of Javascript for this, using the Intersection Observer API. This allows us to create an observer that watches for elements intersecting with the viewport, triggering a callback function when this occurs. It is more efficient than libraries that rely on continuously listening for scroll events.
We can create an observer that watches for each of our scroll sections coming in and out of view:
const sections = [...document.querySelectorAll('section')]
const options = {
rootMargin: '0px',
threshold: 0.25
}
const callback = (entries) => {
entries.forEach((entry) => {
if (entry.intersectionRatio >= 0.25) {
target.classList.add("is-visible");
} else {
target.classList.remove("is-visible");
}
})
}
const observer = new IntersectionObserver(callback, options)
sections.forEach((section, index) => {
observer.observe(section)
})In this example, a callback function is triggered whenever one of our sections intersects the container by 25% (using the threshold option). The callback adds a class of is-visible to the section if it is at least 25% in view when the intersection occurs (which will take effect when the element is coming into view), and removes it otherwise (when the element is moving out of view). Then we can add some CSS to transition in the content for each of those sections:
section .content {
opacity: 0:
}
section.is-visible .content {
opacity: 1;
transition: opacity 1000ms:
}This demo shows it in action:
See the Pen Scrolling with Intersection Observer by Michelle Barker (@michellebarker) on CodePen.
You could, of course, implement some much more fancy transition and animation effects in CSS or JS!
As an aside, it’s worth pointing out that, in practice, we shouldn’t be setting opacity: 0 as the default without considering the experience if JavaScript fails to load. In this case, the user would see no content at all! There are different ways to handle this: We could add a .no-js class to the body (which we remove on load with JS), and set default styles on it, or we could set the initial style (before transition) with JS instead of CSS.
Position: sticky
There’s one more CSS property that I think has the potential to aid the scroll experience, and that’s the position property. Unlike position: fixed, which locks the position of an element relative to the nearest relative ancestor and doesn’t change, position: sticky is more like a temporary lock. An element with a position value of sticky will become fixed only until it reaches the threshold of its parent, at which point it resumes relative positioning.
By “sticking” some elements within scroll sections we can give the impression of them being tied to the action of scrolling between sections. It’s pretty cool that we can instruct an element to respond to it’s position within a container with CSS alone!
Browser support and fallbacks
The scroll-snap-type and scroll-snap-align properties are fairly well-supported. The former requires a prefix for Edge and IE, and older versions of Safari do not support axis values. In newer versions of Safari it works quite well. Intersection Observer similarly has a good level of support, with the exception of IE.
By wrapping our scroll-related code in a feature query we can provide a regular scrolling experience as a fallback for users of older browsers, where accessing the content is most important. Browsers that do not support scroll-snap-type with an axis value would simply scroll as normal.
@supports (scroll-snap-type: y mandatory) {
.scroll-container {
height: 100vh;
overflow-y: scroll;
scroll-snap-type: y mandatory;
}
section {
height: 100vh;
scroll-snap-align: center;
}
}The above code would exclude MS Edge and IE, as they don’t support axis values. If you wanted to support them you could do so using a vendor prefix, and using @supports (scroll-snap-type: mandatory) instead.
Putting it all together
This demo combines all three of the effects discussed in this article.
Summary
Spending time on scroll-based styling might seem silly or frivolous to some. But I believe it’s an important part of positioning the web as a viable alternative to native applications, keeping it open and accessible. While these new CSS features don’t offer all of the control we might expect with a fully featured JS library, they have a major advantage: simplicity and reliability. By utilising web standards where possible, we can have the best of both worlds: Slick and eye-catching sites that satisfy clients’ expectations, with the added benefit of better performance for users.
About the author
Michelle is a Lead Front End Developer at Bristol web agency Atomic Smash, author of front-end blog CSS { In Real Life }, and a Mozilla Tech Speaker. She has written articles for CSS Tricks, Smashing Magazine, and Web Designer Magazine, to name a few. She enjoys experimenting with new CSS features and helping others learn about them.