Changeset d8f8f07 in Klonkt

Timestamp:

08/20/2026 02:02:18 AM (3 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

a505f31

Parents:

4989294

git-author:

Robin <roboburr@…> (08/20/2026 01:55:34 AM)

git-committer:

Robin <roboburr@…> (08/20/2026 02:02:18 AM)

Message:

Lezen: het snappunt op een anker van nul hoog, niet op het bericht zelf

Robins melding (20-8): "wanneer we aan de onderkant vlakbij de zone komen
begint het te verspringen; het lijkt alsof de bovenkant van de volgende
post aan de onderkant van de viewport snapt." En de goede vraag erbij: ligt
het aan de browser?

Ja, en volgens de spec -- dus geen bug maar een regel die ik niet kende.

Een snapgebied dat GROTER is dan het scherm mag op elke positie blijven
staan waar het het scherm nog vult. Onze berichten waren zelf het
snapgebied, en twee ervan zijn hoger dan de viewport (812 op dev):

bericht 2 1009px geldig van 700 tot 897
bericht 3 839px geldig van 1709 tot 1736

De bovenste stand van zo'n bereik is de onderkant van dat bericht op de
onderrand -- oftewel de bovenkant van het VOLGENDE bericht op de onderrand.
Precies wat Robin zag. En het "verspringen" volgt eruit: net binnen dat
bereik gebeurt er niets, net erbuiten wel, en die grens ligt midden in je
leesgebied. Onze CSS zei gewoon start; de browser mocht het ruimer nemen.

Gemeten voordat ik iets veranderde: landen op 867 (binnen het bereik van
bericht 2) gaf geen snap, landen op 1706 sprong naar 1709.

De reparatie: het snappunt verhuist naar een leeg <span> van NUL HOOG
bovenin elk bericht. Nul is nooit groter dan het scherm, dus er is precies
een geldige positie -- die bovenrand aan de bovenrand.

Na afloop gemeten:

grens naar bericht 2 -> 701 (doel 700)
grens naar bericht 3 -> 1710 (doel 1709)
oude "onderin"-stand 867 -> 701, geen vangst onderin meer
oude "onderin"-stand 1706 -> 1710

Onderweg een eigen fout gevangen: het anker staat BINNEN de padding van het
artikel, dus het snappunt lag 33px te laag en de scheidingslijn viel net
boven beeld (733 waar 700 hoort). scroll-margin-top: 2rem zet dat recht --
die verschuift alleen het snappunt en niet de opmaak, en blijft in de pas
met de padding-top van .read-post.

De regel voor het laatste bericht blijft staan; dat is een ander geval. Zijn
snappunt is onbereikbaar (2548 tegen een maximum van 2356), en dan snapt de
browser naar de bodem.

style.css naar v81.

Suite 1169/1169.

Co-Authored-By: Claude Opus 5 <noreply@…>

Location:

src

Files:

• assets/css/style.css (modified) (2 diffs)
• views/partials/read-article.ejs (modified) (1 diff)
• views/shell.ejs (modified) (1 diff)

src/assets/css/style.css

@@ -2492 +2492 @@
        ook niet naar zijn eigen bovenrand -- anders trekt proximity je terug
        zodra je een paar regels verder leest. */
-    scroll-snap-align: start;
+    /* Het snappunt zit op .read-anker hierna, niet hier. Zie de toelichting
+       daar: een snapgebied groter dan het scherm heeft een BEREIK aan geldige
+       posities, en de bovenste daarvan zet het volgende bericht op de onderrand. */
+    scroll-snap-align: none;
     scroll-snap-stop: normal;
     /* GEEN min-height meer. Die rekte elk bericht tot een vol scherm, en bij een
@@ -2511 +2514 @@
     box-sizing: border-box;
 }
+/* ONDERIN GEBEURT ER NIETS (Robin, 20-8: "enkel de bovenkant mag snappen, niet
+   de onderkant; onderin mag er niks met de zone gebeuren").
+   Het laatste bericht heeft een snappunt dat de browser NIET KAN BEREIKEN: er
+   zit niet genoeg pagina onder om zijn bovenkant naar de bovenrand te brengen.
+   Gemeten op dev: snappunt 2548, maar de scroll gaat maar tot 2356. De spec
+   laat de browser dan naar de dichtstbijzijnde BEREIKBARE positie snappen, en
+   dat is de bodem -- waardoor het laatste bericht ergens middenin het scherm
+   blijft hangen en het lijkt of er aan de onderkant wordt uitgelijnd.
+   Zonder snappunt scrolt dat laatste stuk gewoon vrij uit tot het einde. */
+/* HET SNAPPUNT. Nul hoog, dus precies EEN geldige positie: deze bovenrand aan de
+   bovenrand van het scherm. Zat de uitlijning op het artikel zelf, dan gold voor
+   elk bericht dat hoger is dan het scherm een heel BEREIK aan geldige posities
+   (spec: een snapgebied groter dan de snapport mag overal staan waar het de
+   snapport nog vult). Gemeten op dev: bericht van 1009px op een scherm van 812
+   -> geldig van 700 tot 897, en op 867 bleef hij dus gewoon staan. Die bovenste
+   stand, 897, is de onderkant van dat bericht op de onderrand -- oftewel de
+   bovenkant van het VOLGENDE bericht op de onderrand. Dat is wat er onderin
+   leek te snappen, en het kwam van de browser en niet uit onze code. */
+.feed-reader .read-anker {
+    display: block;
+    height: 0;
+    scroll-snap-align: start;
+    /* Het anker staat BINNEN de padding van het artikel, dus 2rem onder de
+       streep. Zonder deze correctie landt de snap 32px te laag en staat de
+       scheidingslijn net boven beeld -- gemeten: 733 waar 700 hoort.
+       scroll-margin verschuift alleen het SNAPPUNT en niet de opmaak, dus het
+       anker blijft waar het staat en de uitlijning klopt met de lijn.
+       Blijft in de pas met de padding-top van .read-post hierboven. */
+    scroll-margin-top: 2rem;
+}
+/* Het laatste bericht krijgt geen snappunt: zijn bovenkant is niet te bereiken
+   (er zit te weinig pagina onder), en de browser snapt dan naar de dichtstbij-
+   zijnde bereikbare positie -- de bodem. Gemeten: snappunt 2548, maxScroll 2356. */
+.feed-reader .read-post:last-child .read-anker { scroll-snap-align: none; }
+
 /* Een lijn tussen twee berichten: zonder grens is een stroom een lange brij. */
 .feed-reader .read-post + .read-post { border-top: 1px solid color-mix(in srgb, currentColor 12%, transparent); }

src/views/partials/read-article.ejs

@@ -20 +20 @@
          data-title="<%= post.title || '' %>"
          aria-label="<%= post.title || '' %>">
+  <%# Het SNAPPUNT, en met opzet een leeg element van nul hoog in plaats van het
+      artikel zelf. Een snapgebied dat GROTER is dan het scherm mag van de spec
+      overal blijven staan waar het het scherm nog vult -- dus bij een bericht
+      van 1009px op een scherm van 812 accepteert de browser elke positie tussen
+      de bovenkant en "onderkant op de onderrand". Die tweede stand zet de
+      bovenkant van het VOLGENDE bericht op de onderrand van het scherm, en dat
+      is wat Robin zag (20-8). Een anker van nul hoog heeft maar een geldige
+      positie: zijn bovenkant op de bovenrand. %>
+  <span class="read-anker" aria-hidden="true"></span>
   <%# De titel is een echte link naar het bericht zelf. De leesstroom toont de
       TEKST, maar reacties, waarderingen en boosts staan op de berichtpagina --

src/views/shell.ejs

@@ -222 +222 @@
 
 <!-- v9 stylesheet (full palette system) -->
-<link rel="stylesheet" href="/assets/css/style.css?v=78">
+<link rel="stylesheet" href="/assets/css/style.css?v=81">
 <script>
 /* iOS safe-area, built by hand. env(safe-area-inset-top) resolves to 0 on this iOS in