Overlap detection lands in CSS with anchors and a shared timeline

Two elements share a row. A big word mark on the left, a section on the right. Resize the window and at some width they crash into each other. You know the shape of the fix. A ResizeObserver, a class toggle, some hand-drawn threshold in JavaScript. On ishadeed.com, Ahmad Shadeed argues you can do the whole thing in CSS.

The move has three parts, and each one leans on a modern primitive.

Anchor two elements, then measure the gap between them

Start with anchor positioning. The decoration gets anchor-name: --line. The section that might collide with it gets anchor-name: --section. That is the opening move. Two names, so the rest of the stylesheet can point at these boxes by handle rather than by DOM position.

Now the trick. A third element, called .measure, is positioned to fill the horizontal space between the two anchors:

.measure {
  left: anchor(--line right);
  right: anchor(--section left);
}

Read that literally. Its left edge sits at the right edge of the line. Its right edge sits at the left edge of the section. When the layout has room, .measure has width. When the two collide, that width collapses to zero. You have turned overlap into a geometry problem you can point CSS at.

Turn size changes into animation progress

Anchor positioning gets the measurement. CSS still has to react to it. That is the scroll-driven animations piece.

The source wires one element with scroll-timeline: --box and drives another with animation-timeline: --box. Once that link exists, the second element's animation is bound to the first element's scroll progress. Changing what is happening on one box becomes progress on somebody else's animation.

That is the small, boring miracle here. Two mechanisms designed for different jobs, anchor positions and scroll timelines, meet in the middle and become an overlap listener.

Why timeline-scope is the piece that makes it composable

There is a catch, and it is the reason the article exists. A named scroll-timeline is scoped to the element that defines it. Only that element and its descendants can see the name. If the thing you want to animate is a sibling, or lives higher up the tree, the name is invisible to it.

timeline-scope fixes that. Put it on a common ancestor and the named scroll-timeline is lifted up to that ancestor's scope, where any descendant can consume it. That is what makes the pattern actually usable. You can put the measurement inside the layout and wire the reaction, hiding the decoration or swapping a color, anywhere in the subtree.

Without timeline-scope, you would be architecturally stuck. With it, the pieces snap together.

What it changes on your next layout

A caveat straight from the source: the demos need a browser that supports both scroll-driven animations and CSS anchor positioning. This is not a technique you can hand every visitor tomorrow.

The design question is the bigger one. For years, "react to layout" meant reaching for ResizeObserver and IntersectionObserver. Those APIs are fine, but they push layout-aware behaviour into JavaScript, where it competes with everything else on the main thread. The pattern in this article does not. The measurement is a positioned element. The reaction is an animation timeline. The wiring is a scoped name.

The interesting next question is not "when does this ship everywhere" — it is what else you have been solving in JavaScript that fits this same shape. Collision. Gap thresholds. Container state that is really about geometry, not media features. Anywhere you were listening to resize to change a class, there is now a CSS-native path worth trying first.