Release 1.21.4

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Give the scroll-to-top target a block box, and take the toolbar lift back out
2026-09-16 22:09:15 +02:00 · 2026-09-16 22:06:58 +02:00 · 2026-09-16 21:56:12 +02:00 · 2026-09-16 21:56:07 +02:00
2 changed files with 8 additions and 1 deletions
@@ -1 +1 @@
-1.21.2
+1.21.4
@@ -492,6 +492,13 @@ body.consent-open{padding-bottom:320px}
@media (min-width:1025px){.visibility-tablet,.visibility-mobile,.visibility-hide-desktop{display:none!important}}
@media (min-width:768px) and (max-width:1024px){.visibility-desktop,.visibility-mobile,.visibility-hide-tablet{display:none!important}}
@media (max-width:767px){.visibility-desktop,.visibility-tablet,.visibility-hide-mobile{display:none!important}}
 /* Das Sprungziel des Knopfs „nach oben“, ein leerer <span> am Anfang von <body>.
   WebKit springt nicht zu einem Ziel, dessen Box inline ist und keine Flaeche hat - der Tipp
   kam an, #seitenanfang stand in der Adresse, und die Seite blieb stehen. Auf dem iPhone,
   und ebenso in Safari auf dem Mac; Chromium ist toleranter, deshalb fiel es am Schreibtisch
   nie auf. Ein leerer Block ohne Hoehe reicht WebKit, es ist die Inline-Box, die stoert.
   Nachgestellt in Playwright-WebKit mit iPhone-Profil: inline bleibt bei 1500, block springt. */
 #seitenanfang{display:block}
 /* Der Knopf „nach oben". Ein Anker, kein Skript: er springt an den Anfang der Seite, und das
   kann ein Browser seit jeher allein. Eingeblendet wird er beim Scrollen über eine Scroll-
   Zeitachse - dieselbe Technik wie bei den Einblendungen. Wo es die nicht gibt (heute noch
Author	SHA1	Message	Date
kantarciandClaude Fable 5.1	ab9e6a7ea0	Release 1.21.4 CMS quality / php (8.2) (push) Canceled after 0s Details CMS quality / php (8.4) (push) Canceled after 0s Details CMS quality / browser (push) Canceled after 0s Details CMS quality / mysql (push) Canceled after 0s Details Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-16 22:09:15 +02:00
kantarciandClaude Fable 5.1	8328bf0964	Give the scroll-to-top target a block box, and take the toolbar lift back out Umut, after 1.21.3: "fix hat nichts gebracht" - and the fix could not have, for two reasons. kant-it.de still runs 1.20.1, so nothing since then was ever live there. And the diagnosis behind 1.21.3 rested on a test that proved nothing: Safari's folded address bar shows only the domain, never the fragment, so "nothing in the address bar" said nothing about whether the tap had arrived. Reproduced this time in the real engine: Playwright's WebKit with the iPhone 14 profile. The tap arrives, #seitenanfang lands in the URL, and scrollY stays at 1500. Setting location.hash directly does the same. In the desktop profile as well, so this is Safari on the Mac too. Chromium jumps to 0. Narrowed down with fourteen variants of the target: WebKit does not scroll to a fragment target whose box is inline and has no area. The same empty span with display:block jumps; an empty div with no height jumps; #top, #main and body jump. It is the inline box, not the size. The section anchors are not affected - position:absolute already blockifies them and they jump in WebKit. So the target gets display:block, one rule in site.css. The template stays as it is. And the lift from 1.21.3 comes out again: --kant-browser-chrome and the six places that added it to bottom or padding. It moved the button and the consent bar up by the folded toolbar's height on every iPhone, for a cause that turned out not to be the cause. On the desktop it was zero anyway. WebKit iPhone 14 after the change: tap 0, click 0, hash 0. Chromium unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-16 22:06:58 +02:00
kantarciandClaude Opus 5	245f189d57	Release 1.21.3 CMS quality / php (8.2) (push) Canceled after 0s Details CMS quality / php (8.4) (push) Canceled after 0s Details CMS quality / browser (push) Canceled after 0s Details CMS quality / mysql (push) Canceled after 0s Details Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-16 21:56:12 +02:00
kantarciandClaude Opus 5	99b3aba39a	Lift what sticks to the bottom above the browser's own bar Umut: "Beim Smarphone/iphone geht der button scroll to top nicht. hier gehts." The button was there and did nothing, on every page of every installation, and tapping it did not even put #seitenanfang in the address bar - so the tap never reached the page. Safari on the iPhone folds its address bar into a narrow strip while reading and lays that over the content. A fixed element measures its "bottom" against the full viewport, not against the part that is left: the button stood in the strip the browser had taken for itself. Drawn, visible, and every tap landed on the bar. Measured at 390x844 the button occupies y 780 to 828 - the bottom 64 pixels, which is where that strip sits. The difference between the large viewport (bar folded) and the small one (bar out) is exactly that height, so --kant-browser-chrome carries it and the pieces that stick to the bottom add it. Where there is no such bar it is zero and nothing moves. The @supports around it is not caution but necessity: a browser that does not know lvh/svh would find the calculation invalid at computed-value time, and bottom would fall back to auto - the button would then stand anywhere. The consent bar has the same geometry, so "Annehmen" and "Ablehnen" were just as hard to hit. It is lifted the same way, except where it is glued to the edge - raising it there would leave a gap with the page showing through, so its bottom padding grows instead and the buttons move up with it. Verified with a test page that sets the height to 50px, the only way to see the effect without an iPhone: the button moves up by exactly 50px, the glued bar keeps its edge and its padding goes from 16px to 66px. On the real page in Chromium bottom stays 16px and the jump still goes 1500 to 0. Not verified on a real iPhone - that needs the device. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-16 21:56:07 +02:00