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 · 2026-09-16 21:30:23 +02:00 · 2026-09-16 21:30:19 +02:00
2 changed files with 21 additions and 5 deletions
@@ -1 +1 @@
-1.21.1
+1.21.4
@@ -438,9 +438,14 @@ body.consent-open{padding-bottom:320px}
 .kant .width-full>.section-inner{width:100%;max-width:none;margin-inline:0}
@media (max-width:767px){.kant .width-wide>.section-inner{width:calc(100% - 36px)}}

-/* A section that is a flex container centres its content box; the inner container must then be
-   allowed to grow, or a full height section would show a strip in the middle. */
-.block-section>.section-inner{flex:1 1 auto}
+/* Ein Abschnitt, der ein Flex-Kasten ist, reiht seinen Inhaltskasten als Flex-Element ein.
+   Wachsen darf der dabei nicht: die Laufrichtung ist voreingestellt die Zeile, und dort frisst
+   das Wachsen die Randluft des Containers. Auf dem Telefon stand der Text eines Hero-Abschnitts
+   damit hart an der Kante, waehrend Kopf und alle uebrigen Abschnitte ihre 18 px hatten - am
+   Schreibtisch fiel es nicht auf, weil dort die Hoechstbreite des Designs vorher bremst.
+   Die Hoehe braucht das Wachsen nicht: quer zur Laufrichtung dehnt sich ein Flex-Element
+   ohnehin ueber die volle Hoehe, und steht "Ausrichtung: Mitte", ist die Mitte gewollt. */
+.block-section>.section-inner{flex:0 1 auto}

 /* Menu kinds. Horizontal is the default; vertical stacks; burger is a details element, so it
   opens without a script - a menu that needs one would not open on a page that runs none. */
@@ -472,9 +477,13 @@ body.consent-open{padding-bottom:320px}
   weder faerben noch abschalten. Linie und Schatten kommen dann aus Rahmen und Wirkung. */
 .site-header.is-sticky.has-own-surface{background:transparent;box-shadow:none}
 .site-header .menu-burger[open]>summary{border-radius:8px}
+/* Die Flaeche malt ihren eigenen Untergrund, also setzt sie auch ihre eigene Schriftfarbe.
+   Ohne das erbte sie die Farbe des Kopfbereichs: bei einem Kopf, der ueber einem dunklen Bild
+   schwebt und deshalb weiss schreibt, stand das aufgeklappte Menue weiss auf weiss. */
 .site-header .menu-burger-body{position:absolute;left:0;right:0;top:100%;z-index:30;
  padding:15px max(16px,calc((100% - var(--k-container,1180px)) / 2 + 16px)) 25px;
-  background:var(--paper);box-shadow:0 15px 25px color-mix(in srgb,var(--ink) 12%,transparent)}
+  background:var(--paper);color:var(--ink);
+  box-shadow:0 15px 25px color-mix(in srgb,var(--ink) 12%,transparent)}
 .site-header .menu-burger-body .menu-list{gap:0}
 .site-header .menu-burger-body .menu-list a{padding:12px 10px;font-size:16px}
 /* Visibility never overwrites the block's grid/flex/display settings. */
@@ -483,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
kantarciandClaude Opus 5	c91f996524	Release 1.21.2 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:30:23 +02:00
kantarciandClaude Opus 5	0ed4c83e41	Fix the mobile menu writing white on white and the hero losing its gutter Umut on Elektro Bernhard: "Menü im Mobil Dropdown textfarben sind weiß also weiß auf weiß und Hero banner texte sind ohne abstand rechts links im mobil". Both are core faults, not content - every site with a floating header and a flex section had them. The opened burger panel paints its own white surface but took its text colour from the header. A header that hovers over a dark photo writes white, so the menu was white on white until the page was scrolled and the header turned light. The design area has settings for the burger button - text, surface, border, corners, size - but none for the panel, so there was no way to fix this from the editor. The panel now sets its own colour alongside its own background. The gutter was lost to "flex:1 1 auto" on .section-inner, added in `67b8575` so a full height section could grow. Growing works along the main axis, and that defaults to the row: the inner box grew sideways and pushed the container gutter out. On the desktop the theme's maximum width stopped it before anyone noticed; on a phone there is none, and the text sat hard against the edge while the header and every other section kept their 18px. It is "flex:0 1 auto" now. The height never needed it - across the main axis a flex item stretches anyway, and where "align-items: center" is set, the middle is what was asked for. Measured at 375px: hero content was x 0 / 375 wide, now x 18 / 339, the same as the header. At 1440px nothing changes (x 93 / 1240). Checked against the full screen hero template as well - edge to edge, 100dvh, content centred - which renders as before. 579 PHP tests / 4798 assertions on 8.4 and 8.2, 35 JavaScript model tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-16 21:30:19 +02:00
@@ -1 +1 @@
 .21.1
 .21.4