Snap + Progress

.sn-progress-wrapper (position: relative, 100 % × 280 px) contient trois choses. La piste .sn-progress-bar-track (absolue en haut, 3 px, blanc à 10 %, z-index: 5) avec son remplissage #snProgressBarFill : dégradé 90° #6366f1 → #d946ef, width: 0%, transition: width .3s. La colonne #snProgressDots (absolue, top: 10px; right: 8px, flex vertical, gap: 6px) : cinq div.sn-progress-dot de 8 px, blanc à 20 %, cursor: pointer, transition: .3s ; la classe .active les passe en #8b5cf6 et scale(1.3) (10,4 px mesurés). Et le défileur #snProgressContainer (100 % × 280 px, overflow-y: auto, scroll-snap-type: y mandatory, scroll-behavior: smooth) qui empile cinq .sn-progress-section de 280 px en scroll-snap-align: start, flex centré, padding: 20px, chacune avec son dégradé à 135° (#1e1b4b → #312e81 pour la première, #7c3aed → #8b5cf6 pour la dernière), un h4 de 0,9 rem (avec un font-family: Inter… en ligne dans le HTML), un p de 0,72 rem en blanc à 60 % et un numéro .sn-section-number de 3 rem à 8 % de blanc en filigrane. Mesuré : scrollHeight 1400, clientHeight 280, course de 1120 px. Le prélude .demo-preview qui enveloppe le tout apporte le box-sizing: border-box de tous les descendants et l'indication « Scrollez ↓ » qui pulse en 2 s.

Un seul écouteur scroll sur le conteneur fait tout le travail, sans requestAnimationFrame ni IntersectionObserver. Il calcule progress = scrollTop / (scrollHeight − clientHeight) × 100 et l'écrit dans barFill.style.width ; puis currentSection = Math.round(scrollTop / clientHeight) et bascule .active sur le point de cet index. Mesuré aux cinq positions de repos : 0, 25, 50, 75 et 100 % — le pourcentage est une position dans la course, pas un compte de sections : la première section lit 0 % et la dernière seule atteint 100 %. Le point, lui, bascule à mi-section (139 px → point 1, 141 px → point 2). Comme la barre a une transition de 0,3 s, elle est en retard sur la valeur : 80 ms après un coup de molette, le style dit 51 % quand la largeur rendue mesure 28 % (209,7 px sur 744).

L'accroche des sections est faite par le CSS (mandatory), pas par le JS. Mesuré dans Chromium 151 : un coup de molette de 60 px déplace de 42 px puis ramène à 0 (la barre affiche 3,75 % puis 0 %) ; 120 px → 85 px puis retour ; 200 px → 280 px, la deuxième section ; 300 px = exactement une section par coup ; au-delà de la fin, 1120 px et 100 % restent. Un clic sur un point appelle container.scrollTo({ top: index × clientHeight, behavior: 'smooth' }) : le lissage est celui du navigateur, mesuré sur 840 px (point 1 → point 4) : 27, 192, 505, 671, 744, 789, 817, 834, 840 px à 50 ms d'intervalle, soit ≈ 450 ms ; 280 px en ≈ 400 ms. Les événements scroll émis pendant ce lissage font suivre barre et points en continu. Les seuls écouteurs sont ceux du conteneur et des cinq points : ils disparaissent avec le DOM, rien n'est posé sur window. Le CSS vendu contient en revanche 18 règles étrangères à l'effet (.customizer-panel, .code-tab, .favorite-btn…), 1,5 Ko sur 4,2, qui ne ciblent rien.

Code ES5 (var, function, forEach) ; requiert scroll-snap-type / scroll-snap-align (spécification finale), scroll-behavior: smooth, Element.scrollTo() avec objet d'options, classList.toggle(nom, force) et linear-gradient. Ni IntersectionObserver, ni requestAnimationFrame, ni animation-timeline : barre et points sont pilotés par l'événement scroll classique, ce qui inclut Firefox, qui ne supporte les animations pilotées au défilement en CSS natif dans aucune version. Zéro dépendance.