From adaaf7f3e34cf8eb34190feab0b7d3ed2b903050 Mon Sep 17 00:00:00 2001 From: Bendik Aagaard Lynghaug Date: Thu, 6 Aug 2026 15:37:49 +0200 Subject: [PATCH] Add plain-unit fallbacks for svmin/svh in case of unsupported engines Couldn't reproduce the reported "hero-yes doesn't show" in a live WebKitGTK check (svmin/svh both resolved correctly there), but an engine that doesn't support these newer viewport units would treat the whole declaration as invalid and drop it - for .hero-yes's height that means falling through to auto, which collapses the section to its in-flow content height and clips the canvas via overflow:hidden. Declaring a plain px/vh value first means an unsupported engine keeps that instead of falling through further. --- style/main.css | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/style/main.css b/style/main.css index 1596562..da452f1 100644 --- a/style/main.css +++ b/style/main.css @@ -54,7 +54,12 @@ -based units recalculate as mobile Safari's address bar hides/shows on scroll, which would reflow every text size on the page mid-scroll; svmin stays fixed to the smallest viewport state, - same stability .hero-yes already gets from 100svh below. */ + same stability .hero-yes gets from 100svh below. + Plain-px fallback declared first: an engine that doesn't + understand svmin/calc() here treats the whole line as invalid and + ignores it, leaving this in effect instead of falling through to + the UA default. */ + font-size: 17px; font-size: max(12px, calc(2.1svmin + 3pt)); } @@ -137,6 +142,12 @@ main.loading, main.not-found { position: relative; max-width: none; width: 100%; + /* plain-vh fallback first - same reasoning as :root's font-size + above: an engine without svh support ignores the invalid second + line rather than falling through to auto height, which would + collapse this to the height of its in-flow content and clip the + canvas via overflow:hidden below. */ + height: 100vh; height: 100svh; padding: 0; justify-content: flex-end;