source: Klonkt/src/views/partials/read-article.ejs@ d8f8f07

main
Last change on this file since d8f8f07 was d8f8f07, checked in by Robin <roboburr@…>, 3 weeks ago

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

  • Property mode set to 100644
File size: 5.0 KB
Line 
1<%
2// Eén bericht in de leesstroom.
3//
4// Dit is het stuk dat de client AANVULT: bij de onderrand komt de oudere buur
5// eronder, bij de bovenrand de nieuwere erboven. Geen sprongen, geen
6// scrollpositie die stiekem verzet wordt -- de stroom groeit gewoon in de
7// richting waarin je leest, en de browser snapt naar de grenzen.
8//
9// Elk artikel draagt zijn eigen buren, dus de client hoeft niets te onthouden:
10// wat er nog te halen valt staat op het stuk dat er al is.
11var _b = (typeof siteUrlBase !== 'undefined' && siteUrlBase) ? siteUrlBase : '';
12var _newer = (typeof newerPost !== 'undefined' && newerPost) ? newerPost : null;
13var _older = (typeof olderPost !== 'undefined' && olderPost) ? olderPost : null;
14%>
15<article class="read-post"
16 data-slug="<%= post.slug %>"
17 data-newer="<%= _newer ? _newer.slug : '' %>"
18 data-older="<%= _older ? _older.slug : '' %>"
19 data-base="<%= _b %>"
20 data-title="<%= post.title || '' %>"
21 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>
31 <%# De titel is een echte link naar het bericht zelf. De leesstroom toont de
32 TEKST, maar reacties, waarderingen en boosts staan op de berichtpagina --
33 en een stroom waar je niet uit kunt naar het gesprek is een doodlopende weg.
34 Een <a> en niet alleen een tik-afhandelaar: dat werkt ook met een
35 toetsenbord, met een schermlezer, en met cmd-klik. %>
36 <%# De cover hoort hier net zo goed als op de berichtpagina: het is het beeld
37 van het stuk, en zonder hem begint elk bericht in de stroom met kale tekst.
38 Boven de titel, in dezelfde volgorde als post.ejs.
39
40 Twee dingen komen hier van post-card en NIET van post.ejs:
41
42 - De SLUIER. Op de berichtpagina hangt de waarschuwing als banner boven de
43 hele pagina, want daar staat een bericht. In een stroom kan dat niet: de
44 buren rollen gewoon voorbij, dus het beeld moet zijn eigen sluier dragen
45 of het is onderweg al te zien. De afhandelaar zit gedelegeerd op
46 document (shell.ejs), dus hij werkt ook op wat de client later aanschuift.
47 - thumb(). De bron kan het volle bestand zijn en hier staan er meerdere
48 onder elkaar in een stroom die dooraanvult.
49
50 cover_image_url en cover_video_url komen mee: beide voedingen van
51 readerItems() halen `SELECT p.*` op (routes/posts.js, de pinned- en de
52 gewone feed-query). Nagekeken, want een versmalde lijst zou hier niets
53 opleveren zonder ergens te klagen. %>
54 <% if (post.cover_image_url || post.cover_video_url) { %>
55 <figure class="read-cover<%= post.nsfw ? ' nsfw-media' : '' %>">
56 <% if (post.cover_image_url) { %>
57 <img src="<%= thumb(post.cover_image_url, 1280) %>"
58 srcset="<%= thumb(post.cover_image_url, 640) %> 640w, <%= thumb(post.cover_image_url, 1280) %> 1280w"
59 sizes="(min-width: 768px) 46rem, 100vw"
60 alt="<%= post.cover_alt || '' %>" loading="lazy" decoding="async"<% if (post.cover_video_url) { %> data-ios-mp4="<%= post.cover_video_url %>"<% } %>>
61 <% } else { %>
62 <video src="<%= post.cover_video_url %>" poster="<%= thumb(post.cover_video_url, 1280) %>"
63 controls loop muted playsinline preload="metadata"></video>
64 <% } %>
65 <% if (post.nsfw) { %><span class="nsfw-veil"><%- include('nsfw-veil', { cw: post.content_warning }) %></span><% } %>
66 </figure>
67 <% } %>
68
69 <header class="read-head">
70 <h1 class="read-title"><a href="<%= _b %>/<%= post.slug %>"><%= post.title || '' %></a></h1>
71 <% if (post.published_at) { %><p class="read-when"><%= formatDateTime(post.published_at) %></p><% } %>
72 </header>
73
74 <%- include('post-body', {
75 post: post, access: entry.access, teaser: entry.teaser,
76 content_html: entry.content_html, _base: _b,
77 }) %>
78
79 <%# Zegt waar je heen gaat, in plaats van te vertrouwen op een tik die niemand
80 ziet. De tik-afhandelaar in mod/read.js is het gemak; dit is de aankondiging.
81
82 #fediverse is de sectie op de berichtpagina met de ⭐/🔁/💬-tellers en de
83 reacties (post.ejs). Alleen DEZE link springt daarheen: de titel en de tik
84 openen het bericht bovenaan, want die zeggen "lees dit", niet "laat het
85 gesprek zien". Staat de sectie er niet -- AP uit, of een concept -- dan
86 negeert de browser de anker en beland je gewoon bovenaan. %>
87 <footer class="read-foot">
88 <a class="read-open" href="<%= _b %>/<%= post.slug %>#fediverse"><%= t('read.open') %> &rarr;</a>
89 </footer>
90</article>
Note: See TracBrowser for help on using the repository browser.