Sometimes designers have silly ideas that eventually grow on you. That happened to me with this concept where I had to build columns of items moving in opposite directions when a user scrolls the page.
Note: This demo respects reduced motion settings, so you’ll need to enable motion to see the effect. And we’re looking at Chrome and Safari support as I’m writing this.
It’s really not as hard as you might think, thanks to modern CSS features, specifically scroll-driven animations. Mot only that, but it’s fun to make, too! Let me show you how I approached it — and maybe you will want to share how you would do it differently.
The HTML consists of a parent element (.opposing-columns), its children (.opposing-column), and its children’s children (.opposing-item):
<div class="opposing-columns">
<!-- Column 1 -->
<div class="opposing-column">
<div class="opposing-item">...</div>
<div class="opposing-item">...</div>
<div class="opposing-item">...</div>
</div>
<!-- Column 2 -->
<div class="opposing-column">
<div class="opposing-item">...</div>
<div class="opposing-item">...</div>
<div class="opposing-item">...</div>
</div>
<!-- Column 3 -->
<div class="opposing-column">
<div class="opposing-item">...</div>
<div class="opposing-item">...</div>
<div class="opposing-item">...</div>
</div>
</div>This is all we need in the markup. CSS will do the rest!
First off, we’re going to set things up so that this effect only applies to larger screens — there’s no real sense supporting something like this on smaller screens because we need the additional space for the effect.
/* Just on larger screens */
@media screen and (width >= 50rem) {
.opposing-columns {
display: flex;
gap: 2rem;
max-inline-size: min(90dvi, 50rem);
margin-inline: auto;
}
}We need to do a few more things with the parent container to get the illusion that items in each .opposing-column are disappearing as they scroll past it. The items in the outer columns move upward on scroll, and items in the center column move downward. As they cross the parent’s boundaries, we want them to sorta fade out.
So, we’re going to do a few things. First, we’ll set a background color variable on the document as a whole:
@media screen and (width >= 50rem) {
:root {
--opposing-bg: lightcyan;
background-color: var(--opposing-bg);
}
.opposing-columns {
/* same styles as before */
}
}Second, we’ll apply that same background color on the parent’s :before and :after pseudo-elements:
@media screen and (width >= 50rem) {
:root {
--opposing-bg: lightcyan;
background-color: var(--opposing-bg);
}
.opposing-columns {
/* same styles as before */
&:before,
&:after {
content: "";
position: absolute;
inset-inline: 0;
block-size: calc(var(--opposing-mask) * 3);
pointer-events: none;
z-index: 1;
}
}
}Notice that we’ve established a stacking context on the pseudos and set them one layer above the parent and its descendants. This is key for masking the items in each column as they scroll in and out of the container. Thew items are technically sliding under the pseudo masks.
Speaking of which, let’s create another variable called --opposing-mask that adds vertical space between the parent element and the three columns:
@media screen and (width >= 50rem) {
:root {
--opposing-bg: lightcyan;
--opposing-mask: 3rem;
background-color: var(--opposing-bg);
}
.opposing-columns {
display: flex;
gap: 2rem;
max-inline-size: min(90dvi, 50rem);
margin-inline: auto;
margin-block: var(--opposing-mask, 3rem);
position: relative;
}
}
Let’s do the same thing to the parent’s pseudos, only applying --opposing-mask to their block-size by a multiple of three. This way, there’s additional vertical space between them and the parent.
@media screen and (width >= 50rem) {
:root {
--opposing-bg: lightcyan;
--opposing-mask: 3rem;
background-color: var(--opposing-bg);
}
.opposing-columns {
/* same styles as before */
&:before,
&:after {
content: "";
position: absolute;
inset-inline: 0;
block-size: calc(var(--opposing-mask) * 3);
pointer-events: none;
z-index: 1;
}
}
}
You might see where this is going. We have a nice amount of space between the parent container and its pseudos. We want the column items to appear as if they are fading out as they scroll out of the parent container. We don’t have to mess with their opacity or anything like that. Instead, we can add background gradients on the pseudos.
The :before pseudo is at the top of the container, so we’ll give it a gradient that goes from a solid color that matches the document’s underlying background color to transparent, top-to-bottom. And since the :after pseudo sits at the bottom of the parent container, we’ll reverse the gradient so it goes transparent to the document’s background color, bottom-to-top.
@media screen and (width >= 50rem) {
:root {
/* same styles as before */
}
.opposing-columns {
/* same styles as before */
&:before,
&:after {
/* same styles as before */
}
&:before {
background-image: linear-gradient(
to bottom,
var(--opposing-bg) var(--opposing-mask),
transparent
);
inset-block-start: calc(var(--opposing-mask) * -1);
}
&:after {
background-image: linear-gradient(
to top,
var(--opposing-bg) var(--opposing-mask),
transparent
);
inset-block-end: calc(var(--opposing-mask) * -1);
}
}
}
}Before we get to the magic, we ought to lay out the items in each column. Each column is a flex item inside the parent, which is a flex container. We’ll let them shrink (flex-shrink: 1) and grow (flex-grow: 1), capping the size at a certain point (flex-basis: 10rem).
We can define all that with the flex shorthand property:
@media screen and (width >= 50rem) {
/* same styles as before */
.opposing-column {
flex: 1 1 10rem;
}
}Now I want those columns to be grid containers so I can use the gap property to insert space between items:
@media screen and (width >= 50rem) {
/* same styles as before */
.opposing-column {
flex: 1 1 10rem;
display: grid;
gap: 2rem;
}
}We totally could have used Flexbox here as well to get access to gap, but the default layout is set to row and we’d have to override that to column. Grid is a little more concise in this situation.
This is what you came for, right? We’ve set everything up so that column items can flow in and out of the parent container on scroll. Now we need to add that scrolling behavior.
This is where the animation-timeline property comes real handy. Normally, a CSS animation just runs on its own. It starts when the page loads (or after a specific delay you set) and ends after however long you set the duration. With animation-timeline, we tell the animation to run based on its scroll position… hence the term “scroll-driven” animation.
We have two supported functions here, scroll() and view(). They’re related but super different in that scroll() runs the animation based on an element’s scroll position. The view() function is similar, but tracks the element’s progress as it enters and exits the scrollport (i.e., the scrollable area of the container it is in).
We’re going with the view() function because we’ve set this up where there is a clear scrollable area inside the parent container. We need to run the animation based on where it enters and exits that area rather than the scroll position of the column items.
This is real interesting because we can tell view() where exactly we want the animation to start once it enters the scrollable area and where to stop once it exits that same area. Like this:
/* Official syntax */
animation-timeline: view([ <axis> || <'view-timeline-inset'>]?);Let’s start by defining the axes:
@media screen and (width >= 50rem) {
/* same styles as before */
.opposing-column {
/* ... */
animation-timeline: view();
animation-range: entry cover;
}
}This is just partially what we want, but what we’re saying is we want the animation to (1) start the very moment is enters the scrollport (entry), and (2) end when it completely leaves the area (cover). We need to be explicitly about the insets because that’s what establishes the animation’s range relative to where it enters and exits. We want the full range, so the entry begins at 0% and the exit is when an item is covered at 100%.
@media screen and (width >= 50rem) {
/* same styles as before */
.opposing-column {
/* ... */
animation-timeline: view();
animation-range: entry 0% cover 100%;
}
}Lastly, we’ll set the animation to run linearly — no need for the items to slow up or down as they scroll.
@media screen and (width >= 50rem) {
/* same styles as before */
.opposing-column {
/* ... */
animation-timing-function: linear;
animation-timeline: view();
animation-range: entry 0% cover 100%;
}
}OK, great. But what we haven’t done is create an animation. We’ve set up what we want it to do when it runs, but we need to define the actual movement.
I want to set up three separate CSS animations:
We could technically set the first animation on both of the outer columns, but I want a third one that is a little bit offset from the first so those columns appear staggered.
@keyframes scroll1 {
from { transform: translateY(var(--opposing-mask)); }
to { transform: translateY(calc(var(--opposing-mask) * -1)); }
}
@keyframes scroll2 {
from { transform: translateY(calc(var(--opposing-mask) * -1)); }
to { transform: translateY(var(--opposing-mask)); }
}
@keyframes scroll3 {
from { transform: translateY(calc(var(--opposing-mask) * .66)); }
to { transform: translateY(calc(var(--opposing-mask) * -.33)); }
}We can create variables for these, of course, should we ever need to update them:
@media screen and (width >= 50rem) {
:root {
--opposing-bg: lightcyan;
--opposing-mask: 3rem;
--animation-1: scroll1;
--animation-2: scroll2;
--animation-3: scroll3;
/* ... */
}
}…and apply them to each column:
@media screen and (width >= 50rem) {
/* same styles as before */
.opposing-column {
/* same styles as before */
}
:where(.opposing-column:nth-of-type(1)) {
animation-name: var(--animation-1);
}
:where(.opposing-column:nth-of-type(2)) {
animation-name: var(--animation-2);
}
:where(.opposing-column:nth-of-type(3)) {
animation-name: var(--animation-3);
}
}While we’re at it, we should disable the animations to respect the user’s settings for reduced motion (and remove the mask, otherwise it might look weird):
@media (prefers-reduced-motion: reduce) {
.opposing-column {
animation: unset;
&:before,
&:after {
content: unset;
}
}
}So yeah, scroll-driven animations are really, really cool. We’re still waiting for Firefox support as I’m writing this, but you can certainly wrap this in @supports to provide a default experience that uses thew scroll annotations and then set a fallback experience for non-supporting browsers, like running on a normal animation timeline:
@supports (animation-timeline: view()) {
/* ... */
}This is just toe-dipping into what scroll-driven animations can do, of course. What sort of things have you made or experimented with? Or would you approach this one differently? Let me know!
Using Scroll-Driven Animations for Opposing Scroll Directions originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.
Chrome has shipped scroll-triggered animations, and is the first browser to do so. If you update to Chrome 146, you can view the demo below, where the background of a square fades in over the duration of 300ms, but only once the whole element is within the viewport.
This is a bit different to how scroll-driven animations work, so in this article I’ll compare them, and then show you how scroll-triggered animations work.
Scroll-triggered animations play for a fixed duration once a certain scroll threshold has been surpassed. (Think JavaScript’s Intersection Observer API but for CSS animations.)
This differs from scroll-driven animations, where animation progression is synchronized with scroll progression (animation-timeline: scroll()) or the degree of intersection (animation-timeline: view()), and thus has no duration.
The key part is timeline-trigger: view() instead of animation-timeline: view(), which waits for the element to be within the threshold instead of measuring how much it’s within it and doing something accordingly. However, let’s start with the actual @keyframes animation, which sets the background:
/* Define the animation */
@keyframes fade-bg-in {
to {
background: currentColor;
}
}It’s set on the .square over the duration of 300ms:
.square {
/* Declare animation */
animation: fade-bg-in 300ms;
}By default, CSS animations trigger when the declaration is applied, but in the expanded snippet below, timeline-trigger overwrites that behavior. Now the animation triggers when the element comes into view(). The --trigger is simply a dashed ident that acts as an identifier for the trigger, whereas entry 100% exit 0% is a timeline range. A timeline range specifies the scroll zone in which the animation activates and is allowed to remain active.
In this case, the animation triggers when the bottom edge of the .square enters the (entry 100%) and untriggers (assuming that it’s still running) when the top edge exits the scrollport (exit 0%). For clarity, entry 0% would trigger the animation when the top edge enters. entry handles the element coming in from the bottom of the scrollport, whereas exit handles it leaving through the top. It’s a bit confusing, but it’s easier to understand if I don’t over-explain it.
.square {
/* Declare animation */
animation: fade-bg-in 300ms;
/* Animation trigger conditions */
timeline-trigger: --trigger view() entry 100% exit 0%;
}For animation-trigger, we first specify which trigger we’re talking about, and then we declare some settings (e.g., play-forwards):
.square {
/* Declare animation */
animation: fade-bg-in 300ms;
/* Animation trigger conditions */
timeline-trigger: --trigger view() entry 100% exit 0%;
/* Animation trigger settings */
animation-trigger: --trigger play-forwards;
}The play-forwards keyword triggers the animation whenever the square becomes completely visible, and since we haven’t declared a fill mode for the animation (using animation-fill-mode or as part of the animation shorthand), which means that the square won’t retain the background after, the animation is more of a flash.
So, we need to build upon this to achieve different results.
animation-fill-mode vs. <animation-action>First, a recap of what the different fill mode values do for animation-fill-mode or as part of the animation shorthand:
forwards: the styles are retained after the animation.backwards: the styles are applied before the animation.both: both behaviors are applied.Now, let’s assume that the <animation-action> is play-forwards (like before) and the fill mode is forwards (both would be redundant because background isn’t even set to begin with):
.square {
animation: fade-bg-in 300ms forwards;
timeline-trigger: --trigger view() entry 100% exit 0%;
animation-trigger: --trigger play-forwards;
}This causes the styles to be retained, but, if the square partially or completely exits the viewport and then reenters it, the animation restarts, which can cause a flash depending on how the animation ends, which is what happens in this instance.
There are two different ways to solve this…
The “lock-in” method: Use play-once instead of play-forwards, which, when combined with forwards, results in the animation playing once, never to restart, and then retaining the styles afterward.
.square {
/* Play once */
animation-trigger: --trigger play-once;
/* Retain the styles */
animation: fade-bg-in 300ms forwards;
timeline-trigger: --trigger view() entry 100% exit 0%;
}The “back-and-forth” method: play-forwards play-backwards animates the element normally when fully visible and in reverse when no longer fully visible. There’s no flash because the element animates backward as smoothly as it animates forward. In addition, even though the direction of the animation can change, the fill mode can remain at forwards instead of being set to both.
Why?
play-forwards means “play the animation from 0% to 100%” whereas play-backwards means “play the animation from 100% to 0%.” Meanwhile, as I mentioned earlier, the forwards fill mode means “retain the styles when the animation completes’”— well, this is regardless of whether the final keyframe is 0% or 100%.
.square {
/* Play forward and backward, as appropriate */
animation-trigger: --trigger play-forwards play-backwards;
/* Retain the styles either way */
animation: fade-bg-in 300ms forwards;
timeline-trigger: --trigger view() entry 100% exit 0%;
}play-forwards, play-once, and play-backwards aren’t the only keywords for <animation-action>. Here’s a quick rundown:
<animation-action> | Effect |
|---|---|
none | For disabling triggers conditionally, on entry but not exit (or vice-versa), or handling multiple triggers with one animation-trigger |
play-forwards | Allows the animation to play forward |
play-backwards | Allows the animation to play backward |
play-once | Forward or backward (whichever comes first) |
play | Plays in the last specified direction, or forward if neither has been specified |
pause | Pauses the animation |
reset | Pauses the animation and sets progress to 0 |
replay | Sets progress to 0 but doesn’t pause the animation |
These <animation-action>s not only allow for a significant amount of control over animations while scrolling, but different combinations of actions, fill modes, timeline ranges, and the fact that we can bake exit animations into @keyframes rules means that there are often multiple ways to achieve an outcome.
While scroll-triggered animations being made up of animation actions, fill modes, timeline ranges, and maybe more, might seem overcomplicated, the fact that these mechanics are decoupled enable us to reuse logic while maintaining flexibility, reducing repetition and making the mechanics more design system-friendly.
Consider three squares this time, and for a bit of added complexity, we declare scale: 70% (animates to initial) and define two rotative animations.
<div id="squares">
<div class="square rotate-left"></div>
<div class="square"></div>
<div class="square rotate-right"></div>
</div>/* Define animations */
@keyframes intensify {
to {
scale: initial;
background: currentColor;
}
}
@keyframes rotate-left {
to {
rotate: -5deg;
}
}
@keyframes rotate-right {
to {
rotate: 5deg;
}
}
.square {
/* Set starting value */
scale: 70%;
}After that it’s more of the same, and while it’s obviously a more complex example, being able to merge values into shorthand properties and decouple them into longhand properties, as well as the decoupled nature of the different mechanics, facilitates flexibility but also reusability (in this case, to stagger various animations using the same animation trigger settings):
.square {
/* Set starting value */
scale: 70%;
/* Define animation name */
--base-animation: intensify;
/* Declare animation */
animation: var(--base-animation) 300ms forwards;
/* Define animation trigger settings */
--animation-trigger: --trigger play-forwards play-backwards;
/* Declare for intensify, then for one of either rotate animations */
animation-trigger: var(--animation-trigger), var(--animation-trigger);
/* Declare animation trigger conditions (without timeline ranges) */
timeline-trigger: --trigger view();
/* Declare active range end */
timeline-trigger-active-range-end: normal;
/* Append other animations */
&.rotate-left {
animation-name: var(--base-animation), rotate-left;
}
&.rotate-right {
animation-name: var(--base-animation), rotate-right;
}
/* Stagger activation ranges */
&:first-child {
timeline-trigger-activation-range-start: entry 33.3333%;
}
&:nth-child(2) {
timeline-trigger-activation-range-start: entry 66.6666%;
}
&:last-child {
timeline-trigger-activation-range-start: entry 99.9999%;
}
}Here’s a cleaner, more robust version that uses sibling-count() and sibling-index() (which lack Firefox support) to stagger the animations:
In this version, instead of setting timeline-trigger-activation-range-start on each individual square, we simply target .square and calculate the entry values on the fly:
/* Maximum entry ÷ number of squares */
--stagger-interval: calc(100% / sibling-count());
/* Current square’s index × stagger interval */
--entry: calc(sibling-index() * var(--stagger-interval));
/* Declare animation trigger conditions */
timeline-trigger: --trigger view() entry var(--entry) exit 0%;In this case, we’ll shift the trigger and its ranges to the first square, and have the other squares follow according to a staggered animation delay. As you can see, all animations are triggered by animation-trigger once 50% of the first square has entered (entry 50%) the viewport (view()). animation-trigger is triggered by timeline-trigger because the dashed ident (the aptly named --trigger) links them:
/* Define animations */
@keyframes intensify {
to {
scale: initial;
background: currentColor;
}
}
@keyframes rotate-left {
to {
rotate: -5deg;
}
}
@keyframes rotate-right {
to {
rotate: 5deg;
}
}
.square {
/* Set starting value */
scale: 70%;
/* Define animation name */
--base-animation: intensify;
/* Maximum delay ÷ number of squares */
--stagger-interval: calc(300ms / sibling-count());
/* Current square’s index × stagger interval */
--animation-delay: calc(sibling-index() * var(--stagger-interval));
/* Declare animation */
animation: var(--base-animation) 300ms var(--animation-delay) forwards;
/* Define animation trigger settings */
--animation-trigger: --trigger play-forwards play-backwards;
/* Declare for intensify, then for one of either rotate animations */
animation-trigger: var(--animation-trigger), var(--animation-trigger);
&:first-child {
/* Declare animation trigger conditions */
timeline-trigger: --trigger view() entry 50%;
/* Declare active range end */
timeline-trigger-active-range-end: normal;
}
/* Append other animations */
&.rotate-left {
animation-name: var(--base-animation), rotate-left;
}
&.rotate-right {
animation-name: var(--base-animation), rotate-right;
}
}One downside is that when animation-trigger is in play-backwards mode, the animations don’t stagger. This is because, I think, when the animation is reversed, the delay is included in that. This seems like an oversight to me, especially as that isn’t the case with animation-direction: reverse, but I could be completely wrong on this.
Timeline ranges are a big part of scroll-triggered animations, but they’re a separate mechanic. For scroll-driven animations, you’ll want animation-range and its longhand properties. With scroll-triggered animations, the syntax is fundamentally the same but uses different properties and two different ranges. The activation range determines the scroll zone in which the animation triggers, while the active range determines the zone in which it holds up (even if not in the activation range anymore).
Timeline ranges are a bit heavy. However, view() entry 100% exit 0% (when fully visible) and view() contain (the same but also if larger than the viewport) will suffice most of the time.
But if you’re keen to dive in, animation-range, although it’s for scroll-driven animations, is lighter and offers a novice-level understanding of timeline ranges. After that, I recommend reading the Animation Triggers spec to cover the many intricacies of timeline ranges within the context of these scroll-triggered animations.
Another ingredient of scroll-triggered animations that’s also its own thing is the view() function, but this one’s easier to summarize here. Basically, when it comes to scroll-triggered animations, view() is the viewport. So if you had a 5rem sticky header, view(y 0 5rem) would make the timeline range factor that in along the y-axis.
Scroll-triggered animations can be tricky because they’re similar to scroll-driven animations, they leverage older CSS features (mainly animation) as well as mechanics from other newer features (dashed idents, view(), timeline ranges), in addition to the CSS properties that are specific to scroll-triggered animations. There’s a whole lot happening at once.
I’m not sure how I feel about them, to be honest. They’re definitely cool, fun, and useful, but they’re also complicated, and it’ll be a while before I really start to rave about them.
A First Look at Scroll-Triggered Animations originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.
With a high of F and a low of 59F. Currently, it's 65F and Fair/Wind outside. Current wind speeds: 20 from the Southeast Pollen: 3...
