Le HTML vendu tient en trois niveaux : le cadre .demo-preview (flex centré, 100% × 280px, overflow: hidden, position: relative, fond #0a0a0f, texte blanc, sans-serif, et la règle box-sizing: border-box pour tout ce qu'il contient), le bloc défilant .sdc-scroll-container (100% × 280px, overflow-y: auto, scroll-behavior: smooth, barre de défilement de 4 px stylée par ::-webkit-scrollbar) et, dedans, dans l'ordre du flux, la piste .sdc-progress-bar (position: sticky; top: 0, 100% × 4px, fond blanc à 10 %, z-index: 10) qui contient le remplissage .sdc-progress-fill (hauteur 100 %, dégradé 90° #8b5cf6 → #ec4899, transform-origin: left, transform: scaleX(0)), puis le contenu .sdc-progress-content : padding: 20px, 800 px de haut, colonne flex à gap: 16px, un h3 de 1 rem graisse 700, un p de 0,78 rem en blanc à 50 % (interligne 1,6) et quatre .sdc-progress-block de 120 px (fond blanc à 4 %, bord blanc à 8 %, rayon 12 px). Sous le cadre, un span.sdc-scroll-hint « Scrollez ↓ » en absolu à 8 px du bas, 0,65 rem, blanc à 30 %, qui pulse jusqu'à 70 % toutes les 2 s. Le champ JavaScript est vide. Mesuré : scrollHeight 804 (800 px de contenu + 4 px de piste, qui est dans le flux), course 524 px.
Le moteur tient en deux déclarations sur .sdc-progress-fill : animation: sdcProgressGrow linear et animation-timeline: scroll(nearest). scroll() remplace l'horloge de l'animation par une timeline de progression de défilement anonyme : 0 % quand le défileur est en haut, 100 % à scrollHeight − clientHeight ; nearest (la valeur par défaut, écrite ici en toutes lettres) désigne le plus proche ancêtre qui défile — .sdc-scroll-container, pas la page — sur l'axe du bloc. Les keyframes vont de scaleX(0) à scaleX(1) ; linear n'est pas un détail : toute autre courbe déforme la proportion (mesuré avec ease-out : 0,68 à mi-course). Mesuré dans Chromium, page vierge, molette par crans de 130 px : 0,248 à 130 px, 0,496 à 260, 0,744 à 390, 0,992 à 520, 1 à 524 — scaleX = scrollTop ÷ 524 au millième ; un scrollTop = 262 posé par script donne 0,5 exactement. getAnimations() renvoie une animation sur une ScrollTimeline dont currentTime est un pourcentage (24,8 à 130 px), finished au bout, running à nouveau dès qu'on remonte. La piste collée ne bouge pas d'un pixel pendant que le titre passe dessous (mesuré : piste à y = 0 du cadre sur toute la course, h3 à −98 puis −492 px). Comme c'est un transform et non une largeur, le dégradé est peint sur toute la largeur puis comprimé : à 50 %, on voit tout le dégradé violet → rose sur la moitié gauche, et la pointe est toujours rose.
Le keyframe from { transform: scaleX(0) } est écrit explicitement, et ce n'est pas redondant. Sans lui, le point de départ est la valeur sous-jacente de l'élément, scaleX(0), une matrice singulière : Chromium interpole quand même les fonctions terme à terme (0,25 / 0,5 / 0,75 aux quarts), mais WebKit 26.5, mesuré, retourne 0,0625 / 0,25 / 0,5625 — le carré de la progression, une barre au quart quand la lecture est à moitié — alors que sa timeline est juste (currentTime 25, 50, 75 %). Avec le from, WebKit rend 0,25 / 0,5 / 0,75 / 1 comme Chromium. L'autre point à connaître est ce que nearest choisit vraiment. Mesuré, effet posé entre 2 000 px de contenu avant et après : la page défilée de 1 900 puis 2 500 px laisse la barre à 0 ; une molette de 262 px sur le cadre la met à 0,5, et la page ne bouge pas. Un second exemplaire dont le contenu ne fait que 200 px, sans débordement : la timeline lui est bien attachée mais reste inactive (currentTime nul), barre vide — elle ne remonte pas à la page. Deux copies sur la même page : aucun id, aucun script, chaque barre ne lit que son cadre. Le scroll-behavior: smooth n'agit pas sur la molette dans Chromium ; un scrollTop = 262 posé par script se relit 0 tout de suite et arrive en 249 ms (493 ms dans Firefox).
