Feature Playground

Data-viz / scrollytelling · 12.5

Section-connecting animated path

A thread tying the argument together.

A dashed path threading between page sections, filling with colour as you scroll and respecting which way you are going.

4 knobs

How it actually works

The layout knob on this page exists to prove exactly one claim. Change it and the cards move; the thread is re-measured and regenerated to find them, and it never has to be redrawn by hand. That is the entire craft of this feature. Budget for the measurement, not for the path.

The drawing is the same stroke-dashoffset walk as 12.3, and it is the boring half. The half that decides whether this ships is that the path must be GENERATED from measured element positions, not authored in a vector editor. A hand-drawn thread that connects four cards at 1280px connects nothing at 390px, and nothing at 1281px either once one card wraps. So: measure each anchor in the read pass, build the d attribute from those points, and rebuild it on resize and on any layout change.

The knobs, named

Layout, curvature, dash pattern, direction response. None are sourced: the article behind this entry was never fetched, and it names no parameters. All four are our design against the mechanism.

KnobSourceWhat it teaches
Layout ours Moves the anchors. The path is regenerated from their measured positions, which is the whole point: nothing here is a hand-authored d attribute.
Curvature ours How far the thread bows out between two anchors. At 0 it is a polyline of straight hops; at 1 it is a ribbon.
Dash pattern ours On the un-filled guide. The filled thread is solid, because on the drawn path the dasharray is already the draw.
Direction response ours What happens when you scroll back up. Instant unfills exactly. Damped lags the retreat, which reads as ink. Latched never retreats, which makes it a trigger, not a thread.

sourced means the source names this parameter. ours means the source names none and the knob is our design against the mechanism. No knob here is invented and passed off as sourced.

Evidence

INFERRED

dev.to "Connect sections by drawing dashed SVG paths on scroll", not fetched. Mechanism shared with 12.3 and 1.12; the index dedupes all three to one mechanism. The re-measurement requirement is the index's own inference, flagged as such there and here.

Seen on
dev.to article (INFERRED). No rendered artifact.
Dependencies
vanilla
Difficulty
moderate — and the difficulty is not the drawing
Performance
The draw is one property per frame. The measurement is the cost, so it is cached and invalidated on resize and layout change, never taken in the write pass.
Accessibility and the floor
Purely decorative, so it is aria-hidden: it repeats a relationship the section order already states. Under .anim-gating the thread renders complete, because a half-drawn thread with no scroll to finish it is just a broken line.
Where our build departs from the source: On a real page the sections scroll and the thread threads between them. Our stage is 440px, which cannot both show four sections and scroll past them, so the stack is pinned and the track behind it supplies the scroll. Letting them scroll instead left two cards on screen and a 17-pixel scroll range, which demonstrated nothing. The measurement, the generation and the direction response are all exactly as they would be on the real page.

Notes

Composability. It is a background layer for a whole page, not a section effect. Run it behind the sections that carry the argument and it does what a numbered list does, without the numbers.

The first version cached the anchor rects at mount. It looked flawless, and it was: at exactly the width it was built at. The regeneration path is not an optimisation to add later, it is the feature. If you are not going to measure, use a straight line and save yourself the afternoon.