Ignore:
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@…>

File:
1 edited

Legend:

Unmodified
Added
Removed
  • src/views/partials/read-article.ejs

    r4989294 rd8f8f07  
    2020         data-title="<%= post.title || '' %>"
    2121         aria-label="<%= post.title || '' %>">
     22  <%# Het SNAPPUNT, en met opzet een leeg element van nul hoog in plaats van het
     23      artikel zelf. Een snapgebied dat GROTER is dan het scherm mag van de spec
     24      overal blijven staan waar het het scherm nog vult -- dus bij een bericht
     25      van 1009px op een scherm van 812 accepteert de browser elke positie tussen
     26      de bovenkant en "onderkant op de onderrand". Die tweede stand zet de
     27      bovenkant van het VOLGENDE bericht op de onderrand van het scherm, en dat
     28      is wat Robin zag (20-8). Een anker van nul hoog heeft maar een geldige
     29      positie: zijn bovenkant op de bovenrand. %>
     30  <span class="read-anker" aria-hidden="true"></span>
    2231  <%# De titel is een echte link naar het bericht zelf. De leesstroom toont de
    2332      TEKST, maar reacties, waarderingen en boosts staan op de berichtpagina --
Note: See TracChangeset for help on using the changeset viewer.