Lezen: het snappen terug naar CSS, en alleen schakelen bij stilstand
Robins bezwaar (20-8): "scroll-snap op het element is iets anders dan touch
events, requestAnimationFrame etc. dan gaan we te veel van de view doen."
Dat klopte. Ik had een scroll-engine in JavaScript gebouwd bovenop een
CSS-functie -- vangzones uitrekenen, snappunten per bericht armeren, de
richting afleiden uit scrollposities -- en dat vecht met de browser in
plaats van hem te gebruiken.
Weg dus: 111 regels snap-logica eruit. Het snappen doet CSS, met
scroll-snap-type:y proximity en scroll-snap-align:start. De bovenkant van
bericht N+1 IS de onderkant van bericht N, dus dat is precies "grijp de
onderkant en snap naar de volgende post".
Nagemeten wat proximity uit zichzelf doet, en dat bleek genoeg:
10, 30, 60, 100, 150, 200px voor de grens -> snapt
300, 400px -> blijft staan
Ongeveer 200-300px vangzone, dicht bij de 150 die ik met de hand nabouwde.
Die hele berekening was overbodig.
WAT ER IN JAVASCRIPT BLIJFT is één schakelaar: scroll-snap-type aan of uit
op de scroller, want omhoog scrollen moet vrij blijven en CSS kent geen
richtingsgevoelig snappen. De richting komt uit de INVOER (wiel, vinger,
toets) en niet uit scroll-events -- die bevatten ook de bewegingen van de
browser zelf, en zijn snap-animatie gaat soms omhoog. Wie daaruit de
richting afleidt leest de browser en niet de gebruiker.
EN ER WORDT ALLEEN GESCHAKELD BIJ STILSTAND. Dat was de tweede vondst, na
Robins melding dat het snappen soms oversloeg en niet op de bovenkant
landde. Gemeten:
snappen UIT, beweging naar 1459 loopt
-> halverwege snappen AAN gezet
-> eindigt op 1459, NIET op een berichtgrens
De browser raadpleegt scroll-snap-type alleen aan het eind van een gebaar
of van de uitloop; zet je hem daar net vóór of ná om, dan krijg je geen
snap of een snap op het verkeerde moment. En de oude code schakelde bij
ELK wiel-event en ELKE vingerbeweging. Bij stilstand omzetten is wel
onschuldig -- dezelfde proef gaf 0px sprong.
Nu dus: richting bepalen bij het BEGIN van een gebaar, daarna niets meer
aanraken tot de scroll stil is (scrollend, met een timer van 120ms voor
browsers die dat event niet kennen; op iOS loopt de uitloop door ná
touchend, dus loslaten is niet hetzelfde als klaar).
Gemeten na de wijziging: omkeren tijdens een gebaar wordt genegeerd,
landing 80px voor de grens komt exact op 1709 uit, en een nieuw gebaar
omhoog zet het snappen uit.
Ook geprobeerd en verworpen: scroll-snap-type:y mandatory zou "direct
snappen" geven, maar trok in een lang bericht 273px terug -- precies de
val die er net uit was.
scroll-behavior:smooth is van de scroller af. Dat maakte elke beweging
traag, ook het snappen; de browser animeert een snap uit zichzelf al en
korter. De terug-naar-boven-knop vraagt zijn animatie expliciet aan en
blijft dus vloeiend, met zijn twee stappen: eerst de top van dit bericht,
dan de kop van de pagina.
style.css naar v78, MOD_V naar 16.
Suite 1169/1169.
Co-Authored-By: Claude Opus 5 <noreply@…>
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
