/* * Safline — viewport & iOS safe-area layer * * Loaded last so it wins over safline.css / tailwind.css for the few root-level * declarations it owns. Everything here exists to make the app render the same * way in mobile Safari and in an installed (standalone) PWA. * * Why the two modes ever differed: * * In mobile Safari the browser chrome already occupies the notch and the * home-indicator strip, so every env(safe-area-inset-*) resolves to 0 and the * browser paints the areas outside the web view itself. Nothing in the app's * safe-area CSS is exercised, which is why Safari always looked right. * * In standalone mode the browser chrome is gone. The home-indicator inset * becomes real (env(safe-area-inset-bottom) is no longer 0), so safe-area * arithmetic that was dormant suddenly drives layout. And the status-bar strip * above the web view is painted by iOS using the *page's* background colour — * the canvas, i.e. the background of / — not the background of * whichever layout
happens to fill the screen. * * Hence the two root fixes below: paint the canvas, and size full-height app * shells with a viewport unit that is stable when browser chrome disappears. */ /* ── Canvas ─────────────────────────────────────────────────────────────────── * * The layout shells paint their own background on a
, which leaves the * document canvas at its default. iOS then colours the standalone status-bar * strip (and the overscroll gutters, in both modes) from that default rather * than from the app's theme — a light strip above a dark app. * * Painting / from the same tokens the shells use makes the strip and * the gutters continuous with the page in both themes. The theme is driven by the * `dark` class the bootstrap script puts on . * * Admin and SuperAdmin sit on the design-system canvas; the public/client shells * sit on the `bg-dashboard` gradient, whose top stop is darker. :has() lets the * canvas follow whichever shell is mounted without any script. */ :root { --saf-app-canvas: #f8fafc; } html.dark { --saf-app-canvas: #071016; } html:has(.saf-shell-console) { --saf-app-canvas: #f5f8fa; } html.dark:has(.saf-shell-console) { --saf-app-canvas: #0f172a; } html, body { background-color: var(--saf-app-canvas); } /* ── Full-height app shells ─────────────────────────────────────────────────── * * For a shell that must be exactly one viewport tall and scroll internally, * `100vh` is wrong on mobile: it resolves to the *large* viewport, so in Safari * the shell runs under the toolbar and its bottom row is unreachable (the shell * itself does not scroll). `100dvh` tracks the viewport that is actually visible * and equals `100vh` on desktop, tablet and in standalone mode, where there is no * retracting chrome. * * Only fixed-height shells use this. Ordinary pages keep `min-h-screen`, where * the large-viewport value is the desirable one — content grows past it anyway. */ .saf-app-shell { height: 100dvh; } /* ── Top inset ──────────────────────────────────────────────────────────────── * * Bars pinned to the top edge grow into the status-bar inset so their own * background, not the canvas, fills it. */ .saf-fixed-top { padding-top: env(safe-area-inset-top, 0px); } /* * Content offset under the fixed public/client navbar. The navbar is 4rem tall * (5rem from `sm`) *plus* the top inset it absorbs above, so a hard-coded rem * offset leaves content underlapping the bar by exactly the inset. Resolves to * the previous fixed value wherever the inset is 0, so browser mode is unchanged. * * Set --saf-navbar-gap for shells that want breathing room below the bar. */ .saf-navbar-offset { padding-top: calc(4rem + var(--saf-navbar-gap, 0rem) + env(safe-area-inset-top, 0px)); } @media (min-width: 640px) { .saf-navbar-offset { padding-top: calc(5rem + var(--saf-navbar-gap, 0rem) + env(safe-area-inset-top, 0px)); } } .saf-navbar-offset--gap { --saf-navbar-gap: 1rem; }