A .sn-vsnap-wrap frame in position: relative, #1e1b4b background, white text, font Inter, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif. Inside it, the .sn-vsnap-container box is 100% × 280px, overflow-y: auto, scroll-snap-type: y mandatory and scroll-behavior: smooth. It holds four .sn-vsnap-section blocks 280px tall in box-sizing: border-box with scroll-snap-align: start: at the end of every gesture the browser finishes the scroll on the top of the nearest section — mandatory forbids any resting position in between. Each section is a centered flex column (gap: 8px, padding: 20px) with a white 0.9rem h4 and a 0.72rem p in white at 60%, on four 135° gradients running from #1e1b4b → #312e81 to #6d28d9 → #7c3aed, indigo to violet. After the box, a span.sdc-scroll-hint reading “Scrollez ↓” in position: absolute anchors to the frame (measured: offsetParent = .sn-vsnap-wrap, 8 px above the bottom of the box, centered) and pulses between 30% and 70% opacity every 2 s. The JS field of the sold code is a single comment: the scrolling engine does all the work.
The box-sizing: border-box line on .sn-vsnap-section is not decorative. Without it, the 20px padding would be added to the 280px and each section would measure 320 px inside a 280 px window (measured with the line removed: scrollHeight 1280, scroll range 1000 instead of 840, text 20 px below the visible center). When a snap area is taller than the snapport, the specification allows any position where the area still covers it: every section would have a 40 px free band inside which the snap holds without switching — a 100 px wheel notch would settle at 40, Arrow Down too, a 600 px notch would land at 640 and the bottom 40 px of every slide would be cut off. With the line, measured in Chromium with the pointer over the box: 280 px sections, 840 px range, text centered to the pixel; a 100 px notch climbs to 82 then returns to 0 (the snap goes to the nearest position: you must cover more than half a section, 140 px, in a single gesture — 150 px settles at 280), two quick 100 px notches make 280, a 600 px notch goes to 560, section 3, skipping section 2 (no scroll-snap-stop).
The gesture isn't read the same way everywhere. Measured on the sold code, blank page, box at rest: Chromium holds the 100 px notch (back to 0) where Firefox 153 and WebKit 26 advance one section (280); at 600 px, Chromium goes to 560, Firefox to 280 (one section per gesture, whatever the amplitude) and WebKit runs to the end of the range, 840. scroll-behavior: smooth only governs programmatic and anchor scrolls: a scrollTop = 280 reaches 280 in 274 ms in Chromium, 199 ms in WebKit and 579 ms in Firefox, and settles there with no overshoot; the wheel is eased by the engine's own snap animation. Two writing choices follow from the code being self-contained. The frame's #1e1b4b background is the start color of the first gradient: the gradients sit on the sections, the frame keeps the box dark on a white page and wherever a mail client doesn't render linear-gradient. The font is declared once, on the frame, and inherited by the headings, the paragraphs and the hint: Inter isn't loaded by the effect, so the browser falls through to the next link in the stack (measured: system-ui in Chromium) — load Inter in your page if you want it, or replace the stack with your own.
CSS only: scroll-snap-type and scroll-snap-align (modern syntax), scroll-behavior, overflow-y, flexbox, linear-gradient, @keyframes. Zero dependencies, zero JavaScript. This is classic CSS, not an animation-timeline-driven animation: the snap works in Firefox (measured in Firefox 153 — same geometry, same stops), whereas animation-timeline scroll effects work in no Firefox version at all.
Without snap support (before Chrome 69, Firefox 68, Safari 11), the box is still a 280 px area that scrolls freely: the sections follow each other with no automatic stop. Without scroll-behavior, only programmatic scrolls lose their easing — wheel and finger are unaffected. Where overflow is not honored (some mail clients), the four sections stack at their own height: everything stays readable, just not as slides; and where gradients aren't rendered, the frame's #1e1b4b background keeps the white text readable.
