/* app/static/css/style.css
Deliberately minimal, plain CSS -- just enough to make the app readable
and usable, not a design system. Nothing here is Flask/Python-specific;
it's included the normal HTML way via in base.html. */
/* CSS custom properties ("variables"): defining the color palette once
here, as named values, instead of typing the same hex codes over and
over throughout this file. Two benefits: it's self-documenting (var()
name says what the color MEANS, not just what it looks like), and
changing the palette later is a five-line edit here instead of a
find-and-replace across the whole file. Referenced elsewhere as
var(--color-name). */
:root {
/* The raw named palette -- these hex values themselves never change
between light/dark mode. Some of them (onyx, cream) play
a role that's the SAME regardless of theme (e.g. navbar text stays
cream because the navbar itself stays a dark graphite in both
modes) -- those are still referenced directly below. Anything whose
role needs to actually FLIP between light and dark (page background,
body text, primary button color...) goes through one of the
SEMANTIC tokens further down instead, which is what actually gets
redefined for dark mode. */
--color-cream: #fffcf2; /* "Floral White" */
--color-taupe: #ccc5b9; /* "Dust Grey" */
--color-onyx: #0f0f0f; /* "Onyx" */
--color-graphite: #2d2e2e; /* "Graphite" -- header/nav background, button hover; stays this same dark shade in both themes on purpose, so the top bar doesn't need its own light/dark logic */
/* These carry actual MEANING (danger, success, ...) rather than being
part of the decorative palette above. Redefined for dark mode below
(same variable names, different values) since their light pastel
backgrounds would look wrong -- too washed-out to read as a banner
-- against a dark page. */
--color-danger: #c0392b;
--color-success-bg: #dff3e3;
--color-success-text: #1e6b34;
--color-error-bg: #fbe1e1;
--color-error-text: #8a1f1f;
--color-info-bg: #e3edfb;
--color-info-text: #1e4a8a;
/* A value the user has deliberately overridden away from what the food
database says. Amber, NOT the app's red: red reads as "you have made
a mistake, fix it before continuing", and this is the opposite --
an intentional correction we accept and save. Amber is the standard
"this is unusual, know what you're doing" register, and it also
keeps --color-danger meaning exactly one thing (a real error) rather
than two. */
--color-edited-bg: #fdf1dc;
--color-edited-text: #7a5312;
--color-edited-border: #c98a2e;
/* A pale wash of the app's own accent, for a callout that is
INFORMATIVE rather than a warning -- the serving-size scaling
notice. Deliberately not --color-bg: on a card, the page
background is nearly invisible and the callout would read as
plain text again, which is the complaint it exists to fix. */
--color-accent-soft: #e4edf1;
/* Semantic tokens -- most rules below use THESE, not the raw palette
above directly. Light mode just points each one at the matching raw
color; dark mode (the two blocks after this one) redefines only
these few names, which is what actually makes the theme switch work
without every single rule needing its own light/dark logic. */
/* Palette redesign, 2026-09-03 (see TODO.md's "COLOR REDESIGN" entry
for the full spec and the reasoning behind each value). The app
moved off the onyx/cream base: light mode is now white with a
slate-blue accent, and dark mode is built on that same slate hue
taken down to a real background weight. The raw cream/onyx/taupe
colors above are still defined -- a few deliberate one-offs below
still use them directly (the graphite button-hover, the auth hero's
fixed dark gradient). The old warm grey is gone entirely; see
--color-muted-fill below for what replaced it and why. */
--color-slate: #3b5d6b; /* the accent -- 7.1:1 on white */
--color-slate-light: #56889c; /* the hero tracker, and dark mode's accent */
--color-ink: #14181a;
--color-ink-muted: #5f6b70;
--color-page-bg: #ffffff; /* body background */
--color-surface: #ffffff; /* cards, the bottom nav, modals -- anything "raised". Same as the page now, so .card's existing border + shadow are what separate it */
--color-text: var(--color-ink); /* primary body text, primary icons */
--color-text-muted: var(--color-ink-muted); /* secondary/muted text */
--color-accent-bg: var(--color-slate); /* primary buttons, active states -- the app's main accent */
--color-accent-text: #ffffff; /* text/icons ON the accent color above */
--color-border: #e4e8ea; /* borders, dividers, subtle fills */
/* Solid "quiet button" fill -- .btn.secondary and the navbar avatar.
Was --color-warm-grey (#716969) before the 2026-09-03 redesign, and
was left behind by it: once everything around it went cool slate,
that warm taupe was the only warm color still on screen and read as
a stray. Same job, same weight (5.5:1 under cream text, so still
AA), just on the new palette's hue. Deliberately the SAME value as
--color-ink-muted, which restores the light-mode collision that the
.hero-day-nav rule near the bottom of this file is written to work
around -- see that rule's comment. */
--color-muted-fill: var(--color-ink-muted);
/* Dashboard header palette, 2026-09-04. Started as a rust/terracotta
pair (the blue read badly on the phone), which Nick then asked to
remove entirely from both themes.
Neutral, NOT a second accent. Set 2026-09-04 on Nick's direct
instruction to remove all terracotta from both themes.
The reason it's neutral rather than another colour: the header
had been rust while every interactive element -- buttons, the
FAB, the active tab -- stayed slate, so the app carried TWO
competing accent hues. A neutral header leaves slate as the
single accent, which is also what the app icon's own
"one accent plus white" brief asks for.
10.84:1 on the cream ground, comfortably past 4.5:1. */
--color-brand-mark: #3a3531;
--color-avatar-bg: #e3ded6;
/* The avatar's fallback person glyph. MUST be paired with
--color-avatar-bg: .navbar-avatar used to hardcode --color-cream,
which was right while the avatar was a dark slate but broke the
moment the header went neutral -- cream on the light #e3ded6 chip
is 1.3:1, an invisible glyph for every user without a profile
picture, in the DEFAULT theme. Change one of these two and you
must re-check the other. 9.29:1 here. */
--color-avatar-fg: #3a3531;
/* The Dashboard's main calorie tracker only -- direct request: it uses
the LIGHTER blue even in light mode, and is the only light-mode
element that does. 3.9:1 on white, above the 3:1 bar for a
graphical element, and 125 away from the standard accent so it
reads as a deliberate choice rather than an inconsistency. */
--color-hero: var(--color-slate-light);
/* The 3 macros. These were hardcoded per-file until this redesign --
in main/routes.py, food/routes.py AND trends.js, none of them
theme-aware. Defined once here now; everything reads from these, so
a ring on the Dashboard and a bar on Trends can't drift apart.
Replaced 2026-09-05, direct request: the original trio (a muted
red/teal/purple) reads as generic "AI dashboard" colors -- it's a
specific, recognizable combination, not just "colorful". Swapped
for a warmer, food-evocative trio instead (terracotta/ochre/plum)
that isn't that particular palette, while keeping each value clear
of the app's own red (--color-danger/--color-chart-goal) and green
(--color-chart-good) so a macro is never confused with a status
color. Weight and calorie chart colors (--color-chart-line, below)
were deliberately left untouched -- only these three moved. */
--color-macro-protein: #111d26;
--color-macro-carbs: #48626f;
--color-macro-fat: #8095a0;
/* Chart geometry uses a distinct slate instead of body-text onyx.
Every solid graphical token here clears 3:1 against the card
surface; dark mode supplies brighter counterparts below.
T239 (Nick, 2026-09-15): DERIVED FROM THE ACCENT, not a literal.
These were #2f6578 / rgba(47,101,120,.14) -- a slate that merely
RESEMBLED the default accent without being linked to it, so T192's
colour picker repainted buttons and left every graph unchanged.
That was the whole of his report: "all they change are a couple
buttons here and there, but the graphs and the rest of the app all
stay the same". One token feeds both the Dashboard and Trends
(dashboard.js TODAY_COLOR and trends.js CHART_LINE_COLOR both read
--color-chart-line), so linking it here repaints every chart.
Contrast: charts need 3:1 against the card surface, and every deep
shade already clears 7:1 against white text -- a far higher bar
against a #ffffff surface. Asserted in test_plus.py so a colour
added later cannot quietly break it. */
--color-chart-line: var(--color-slate);
/* --color-chart-fill was REMOVED by T239, not renamed: the only CSS
way to say "this colour at 14%" once the line became a var() is
color-mix(), and getComputedStyle hands that back UNRESOLVED
("color-mix(in srgb, #3b5d6b 14%, transparent)") -- verified in a
real browser -- which Chart.js's own colour parser cannot read.
trends.js derives the fill from --color-chart-line instead, so
there is one source of truth rather than two that can drift. */
--color-chart-goal: #c0392b;
--color-chart-good: #1e6b34; /* unused since T186 (Trends now uses the steel line colour); kept for the palette notes above */
--color-chart-grid: #777777;
/* Dashboard streak widget's "completed" bubble. Originally gold to
sit near the app's then-warm macro colors (a rust protein and an
olive fat). Those are gone as of the 2026-09-03 palette redesign,
so that rationale no longer holds -- gold is kept anyway because
it now does a different job: it's the one warm note in an
otherwise cool palette, which is exactly what a "you did the
thing" marker wants to be. It was also deliberately protected
during that redesign -- a warm amber accent was rejected for
landing 38 away from this. Brightened slightly for dark mode
below, same reasoning as --color-chart-line: a solid fill needs
more contrast against a dark card than a thin ring stroke does. */
--color-streak-gold: #b3862a;
}
/* Dark mode, system-preference version: applies automatically when the
OS/browser is set to dark, UNLESS the user has explicitly picked Light
via the toggle (see app/static/js/theme_toggle.js), which stamps
data-theme="light" on to opt back out of this. */
@media (prefers-color-scheme: dark) {
:root:not([data-theme="light"]) {
/* Warm-neutral dark ground, 2026-09-04. The previous page/card/
border trio (#101a1e / #19282e / #22333a) repeated the blue
accent hue across every large surface, which is why the whole
theme read too blue on-device. These are low-chroma graphite
values with a slight warm lean; the slate accent remains the
same, so this is a ground adjustment rather than a rebrand. */
--color-page-bg: #181716;
--color-surface: #24211f;
--color-text: #f0ede6;
--color-text-muted: #aaa39a;
--color-accent-bg: var(--color-slate-light);
--color-accent-text: #0d1417;
--color-border: #3a3531;
--color-hero: var(--color-slate-light);
/* Lighter rust for text/linework on the dark ground (6.56:1), plus
a darker avatar fill that clears 3:1 against the page and card
while keeping its cream person glyph at 5.17:1. */
/* Warm grey, matching the light theme's neutral header. See
--color-brand-mark in :root for why this is not a colour.
10.71:1 on the warmed dark ground. */
--color-brand-mark: #cfc7bd;
--color-avatar-bg: #2b2926;
/* Dark keeps the cream glyph -- see --color-avatar-fg in :root
for why this is a token and not a hardcoded value. 14.13:1. */
--color-avatar-fg: var(--color-cream);
/* Brighter counterparts of the 2026-09-05 macro trio, same
reasoning as --color-chart-line's own dark variant: a solid
fill/stroke needs more contrast against a dark card than the
light-mode value would provide. */
--color-macro-protein: #e4edf2;
--color-macro-carbs: #93a8b6;
--color-macro-fat: #5e7280;
--color-success-bg: #16351f;
--color-success-text: #7fd99a;
--color-error-bg: #3a1414;
--color-error-text: #f5a3a3;
--color-info-bg: #16273f;
--color-info-text: #8fb8f0;
--color-edited-bg: #3a2c12;
--color-edited-text: #f0c479;
--color-edited-border: #c99a45;
--color-accent-soft: #1e2e36;
/* T239: the accent's light shade, for the same reason as above. */
--color-chart-line: var(--color-slate-light);
--color-chart-goal: #e07171;
--color-chart-good: #64b77b;
--color-chart-grid: #75706b;
--color-streak-gold: #c79a3a;
}
}
/* Dark mode, explicit-choice version: wins over the system preference in
BOTH directions (picking Dark on a light-mode system, or Light on a
dark-mode system -- see the `:not([data-theme="light"])` guard above,
which is what lets this second block override the first). Same values
as the media-query block; kept as a literal duplicate rather than one
shared block, since CSS custom properties don't have a way to combine
a media query and an attribute selector into a single condition. */
:root[data-theme="dark"] {
/* Keep this literal duplicate in sync with the system-preference
block above: warm graphite ground, unchanged slate accent. */
--color-page-bg: #181716;
--color-surface: #24211f;
--color-text: #f0ede6;
--color-text-muted: #aaa39a;
--color-accent-bg: var(--color-slate-light);
--color-accent-text: #0d1417;
--color-border: #3a3531;
--color-hero: var(--color-slate-light);
/* Keep the header pair in sync with the system-dark block above. */
--color-brand-mark: #cfc7bd;
--color-avatar-bg: #2b2926;
--color-avatar-fg: var(--color-cream);
--color-macro-protein: #e4edf2;
--color-macro-carbs: #93a8b6;
--color-macro-fat: #5e7280;
--color-success-bg: #16351f;
--color-success-text: #7fd99a;
--color-error-bg: #3a1414;
--color-error-text: #f5a3a3;
--color-info-bg: #16273f;
--color-info-text: #8fb8f0;
--color-edited-bg: #3a2c12;
--color-edited-text: #f0c479;
--color-edited-border: #c99a45;
--color-accent-soft: #1e2e36;
/* T239: the accent's light shade, for the same reason as above. */
--color-chart-line: var(--color-slate-light);
--color-chart-goal: #e07171;
--color-chart-good: #64b77b;
--color-chart-grid: #75706b;
--color-streak-gold: #c79a3a;
}
* {
box-sizing: border-box;
}
/* Without this, jumping to any #anchor (e.g. a macro ring on the Dashboard
linking to #macros-chart on Trends) lands that element right at the very
top of the page -- which is now BEHIND the fixed .navbar bar, since it
overlaps that space. scroll-padding-top tells the browser to stop that
much short of the true top for every anchor jump on the site, same
height reserved as .container's own padding-top below. */
/* An anchor jump no longer has to clear a fixed navbar (it scrolls away
with the page now -- see .navbar), so this is just a little breathing
room above the target, matching html.no-navbar's own value below. */
html {
scroll-padding-top: calc(1rem + env(safe-area-inset-top));
}
/* Pages with no fixed navbar at all (see show_navbar in base.html --
every authenticated page but Dashboard) don't need that same reserved
offset for an anchor jump; the Trends page's own macro-ring link (see
#macros-chart) is exactly the kind of jump this affects. */
html.no-navbar {
scroll-padding-top: calc(1rem + env(safe-area-inset-top));
}
body {
margin: 0;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif;
background: var(--color-page-bg);
color: var(--color-text);
}
/* Soften the page-transition flash, direct request ("feels like an app,
not a website"): this app has no client-side router at all (a
deliberate choice, no frontend framework/build step -- see HANDOFF.md)
-- every tab switch is a genuine full-page reload, with a brief flash
straight to the browser's own blank/white paint before this page's
real background ever shows, one of the most obvious "this is a
website" tells there is. Doesn't (and can't, without an actual router)
eliminate the reload itself -- just a quick fade-in of the finished
page softens how the transition FEELS. A plain CSS `animation` runs
on its own the instant this rule applies, no JS/DOMContentLoaded
coordination needed -- and can't itself cause a flash of invisible
content, since the page was already blank during that gap regardless. */
@media (prefers-reduced-motion: no-preference) {
body {
animation: page-fade-in 0.18s ease-out;
}
}
@keyframes page-fade-in {
from {
opacity: 0;
}
to {
opacity: 1;
}
}
.navbar {
/* NOT fixed, as of 2026-09-01 -- direct request, the second half of
"take the header bar out": the logo/name/avatar/gear stay at the
top of the PAGE, but scroll away with everything else rather than
following you down it. Combined with the flattened background
below, there's no longer a "bar" in any visual sense -- just the
page's own first row of content. Consistent with the Dashboard
title, which was changed the same day to scroll away rather than
dock (see .hero-greeting).
Settings stays reachable while scrolled via the native tab bar in
the app, and via the bottom nav on the web, so nothing is lost by
letting this go. */
position: static;
display: flex;
align-items: center;
justify-content: space-between;
flex-wrap: wrap;
/* Direct request: this used to be its own graphite bar, visually
distinct from the page under it. Now it takes the page's own
background instead, so it reads as part of the page rather than a
separate header -- "the same one color look as the others."
Still fixed and still opaque (NOT transparent): page content
scrolls underneath it, so it needs a real background to hide that,
it just needs to be the SAME one the page already uses. */
background: var(--color-page-bg);
padding: 0.75rem 1.5rem;
/* Extra padding to clear the Dynamic Island / status bar on newer
iPhones when installed as a standalone PWA (see viewport-fit=cover
in base.html, required for this to have any effect at all). Without
this, the top bar's content -- the "WeighTooMuch" brand text -- sits right
against/behind that cutout and gets visually clipped. Same idea as
the bottom nav's env(safe-area-inset-bottom), just for the top. */
padding-top: calc(0.75rem + env(safe-area-inset-top));
}
.navbar .brand {
display: flex;
align-items: center;
gap: 0.6rem;
/* Uses the dedicated warm header token so the brand row has its own
identity while action buttons and the active tab stay slate. The
light/dark values both clear 4.5:1 as text. */
color: var(--color-brand-mark);
font-weight: bold;
text-decoration: none;
/* Sized up alongside the icons below -- with no bar behind them
framing them anymore, the old sizes read as small. Raised again to
1.5rem on 2026-09-04, in the same pass that took the logo and gear
to 38px, so the wordmark scales with the marks either side of it
instead of being left behind by them. */
font-size: 1.5rem;
}
/* A masked , not an -- direct request 2026-09-03 that the
brand take the app's accent color.
History worth keeping: logo-mark.png is a fixed CREAM glyph, drawn
back when this bar was always graphite, and it went invisible once the
bar took the page's own background. That was patched with
filter: brightness(0) plus a dark-mode override switching it back off.
That worked only because black and cream were the two colors needed --
brightness(0) flattens every opaque pixel to BLACK and nothing else,
so it could never produce an accent color, and no practical filter
chain lands on an arbitrary hex.
Masking inverts the problem: the PNG supplies only its ALPHA channel
(the glyph's shape), and the color comes from a background
that is just a token. So it tracks light/dark automatically with no
per-theme override at all, and the two blocks that used to do that are
gone. */
.navbar-logo {
/* 38px, matching .navbar-avatar exactly -- direct request 2026-09-04:
the profile icon read as disproportionately large next to the logo,
wordmark and gear, and the call was to keep the avatar as-is and
bring the other three UP to it rather than shrink it. */
width: 38px;
height: 38px;
background-color: var(--color-brand-mark);
-webkit-mask: url("../icons/logo-mark.png") center / contain no-repeat;
mask: url("../icons/logo-mark.png") center / contain no-repeat;
/* A span is inline by default and would collapse to zero height
regardless of the width/height above. */
display: inline-block;
flex: none;
/* No border-radius here -- that rounded a filled tile's corners (the
old icon-192.png usage). logo-mark.png is a transparent glyph with
no tile to round. */
}
/* Settings gear button, Dashboard-only (see base.html) -- opposite the
brand, same icon-button treatment as elsewhere in the app (inline SVG,
fill="currentColor" so it inherits this color rather than emoji). */
.navbar-icon-btn {
/* Accent, matching the brand opposite it -- direct request. The SVG
is fill="currentColor", so this one line colors the gear itself. */
color: var(--color-brand-mark);
display: flex;
align-items: center;
justify-content: center;
width: 44px;
height: 44px;
}
.navbar-icon-btn svg {
/* 38px to match the avatar and logo -- see .navbar-logo above. The
button itself is bumped to 44px so a 38px glyph still has a little
room inside its tap target rather than touching the edges. */
width: 38px;
height: 38px;
}
.navbar-icon-btn:hover {
color: var(--color-text-muted);
}
.container {
max-width: 720px;
margin: 0 auto;
padding: 1.5rem;
/* padding-top is a plain 1.5rem as of 2026-09-01: the navbar above
is no longer fixed (see its own rule), so there's nothing to
reserve room for, and it now sits in normal page flow and absorbs
env(safe-area-inset-top) itself. Pages with no navbar at all still
need that inset here -- see .container.no-navbar further down,
which is why this base rule can't just add it unconditionally.
padding-bottom real bug found and fixed, direct report: 4.5rem only
cleared the bottom-nav BAR's own height -- it didn't also account
for the "+" FAB's circle poking up an extra 22px above the bar's
own top edge (see .bottom-nav-fab-icon's margin-top), so the raised
FAB could visually overlap the last line of .app-footer sitting
right above it on some viewport heights. Bumped to 6rem to give
real clearance above the FAB, not just the flat bar. */
padding-top: 1.5rem;
padding-bottom: 6rem;
}
/* No fixed navbar on this page (see show_navbar in base.html) -- the
3.5rem above exists ONLY to reserve room for that bar, so without it
that space would just be dead air above the page's own
. Only
padding-TOP changes here -- padding-bottom still reserves room for
.bottom-nav, which renders on every authenticated page regardless of
this, Dashboard included.
Real bug, reported directly: this used to be a bare 1.5rem, missing
the env(safe-area-inset-top) the WITH-navbar version above already
includes -- so on an iPhone (notch or Dynamic Island), every page
using this class (Settings and all of its subtabs -- everything but
Dashboard, since that's the only page show_navbar is true for) had
its own
render right under the status bar/notch instead of below
it. Same inset addition as the navbar rule, just without its extra
3.5rem since there's no bar here to reserve room for. */
.container.no-navbar {
padding-top: calc(1.5rem + env(safe-area-inset-top));
}
/* The site-wide disclaimer/Terms link (base.html) -- small and muted so
it doesn't compete with actual page content, but present on every
page. Sits inside .container, after the content block, so it flows
with the page normally and stays clear of the fixed .bottom-nav
(.container's existing padding-bottom already reserves room for that
bar -- see the comment on .container above). */
.app-footer {
margin-top: 2rem;
padding-top: 1rem;
border-top: 1px solid var(--color-border);
/* Direct request, part of the same FAB-overlap fix as .container's
padding-bottom above: smaller text alongside more clearance,
together. */
font-size: 0.7rem;
color: var(--color-text-muted);
text-align: center;
line-height: 1.5;
}
.app-footer a {
color: inherit;
text-decoration: underline;
}
/* T233 / T08 (2026-09-21): the public landing page at `/`.
⚠️ Deliberately plain, and that is the brief. This page exists because
Apple requires a public organization website; it is read once by a
reviewer and occasionally by someone deciding whether to install. It is
not a surface anyone spends time in, so it reuses the app's own tokens
and type scale rather than growing a second visual language to maintain. */
.landing {
max-width: 640px;
margin: 0 auto;
}
.landing-hero {
text-align: center;
padding: 1rem 0 2.5rem;
}
.landing-hero h1 {
font-size: clamp(1.8rem, 7vw, 2.4rem);
line-height: 1.15;
margin-bottom: 0.75rem;
}
.landing-sub {
color: var(--color-text-muted);
font-size: 1.05rem;
line-height: 1.55;
margin: 0 auto 1.5rem;
max-width: 30rem;
}
.landing-cta {
display: flex;
gap: 0.75rem;
justify-content: center;
flex-wrap: wrap;
}
/* Sized like a real call to action rather than inheriting .btn's in-app
proportions -- on this page it is the only thing to do. */
.landing-btn-primary {
min-width: 11rem;
padding: 0.8rem 1.75rem;
font-size: 1.05rem;
}
.landing-note {
color: var(--color-text-muted);
font-size: 0.85rem;
margin-top: 0.9rem;
}
.landing-points {
display: grid;
gap: 1rem;
/* One column on a phone, two once there is room -- no breakpoint to keep
in step with, because auto-fit does it from the available width. */
grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
}
.landing-point {
background: var(--color-surface);
border: 1px solid var(--color-border);
border-radius: 14px;
padding: 1.25rem;
}
.landing-point h2 {
font-size: 1.05rem;
margin-bottom: 0.4rem;
}
.landing-point p {
color: var(--color-text-muted);
font-size: 0.95rem;
line-height: 1.55;
margin: 0;
}
.landing-about {
margin-top: 2.5rem;
text-align: center;
}
.landing-about h2 {
font-size: 1.05rem;
margin-bottom: 0.5rem;
}
.landing-about p {
color: var(--color-text-muted);
line-height: 1.6;
margin-bottom: 0.6rem;
}
/* 2026-09-21 visual review, §1.1. ⚠️ THE SINGLE LOUDEST "THIS IS A WEBSITE"
TELL IN THE NATIVE APP. A centered legal footer with underlined links at
the bottom of every screen -- Home included -- is a web page's furniture;
no Apple app has one. On the SHORT pages (Display, Custom Meals) it was
also stranding itself mid-screen above ~700pt of void, because the page
ran out of content long before the viewport did.
The content is not lost: the same links, and the same medical-advice
line, now live in Settings -> About (onboarding/profile_hub.html), which
is where iOS users look for them. The footer still renders on the WEB,
where a footer is exactly right and where search engines and a first-time
visitor both expect it -- this hides it only inside the wrapper. */
.native-app .app-footer {
display: none;
}
/* 2026-09-21 visual review, §1.2. THE STATUS-BAR SCRIM.
⚠️ THE BUG IT FIXES, seen in the Simulator: scrolling any page put live
content directly behind the clock and the Dynamic Island -- "Grilled
Chick... 420 kcal" rendered on top of 9:41. The WebView's content area
extends into the top safe area (which is correct and is what lets the
page background reach the top of the screen), but nothing was drawn
between that content and the system status bar, so the two collided.
Every iOS app solves this the same way: the area behind the status bar
carries the navigation bar's material, so content passing under it is
frosted rather than legible-on-top-of-the-clock. This is that material
and nothing more.
⚠️ WHY A SCRIM AND NOT A FULL COLLAPSING NAV BAR. A real large-title bar
that collapses on scroll is the right long-term answer (§3.1 of the
review) but it needs every page's title moved out of its card first. This
is the 10-line version that fixes the actual collision today and does not
have to be undone to build that later -- the scrim is what would sit
behind such a bar anyway.
⚠️ env(), NOT a pushed variable, DELIBERATELY -- and the failure mode is
why. --native-safe-area-bottom exists (see its comment above) because a
WRONG bottom inset put the dock off-screen. Here a zero read is harmless:
the scrim collapses to nothing and we are back to today's behaviour, with
nothing mispositioned. The top inset is also already trusted by the
navbar and .container rules above, which do render correctly on device.
pointer-events: none so a fixed strip across the top cannot eat a tap
aimed at whatever is underneath it. */
.native-app::before {
content: "";
position: fixed;
top: 0;
left: 0;
right: 0;
height: env(safe-area-inset-top);
z-index: 100;
background: color-mix(in srgb, var(--color-bg) 72%, transparent);
-webkit-backdrop-filter: saturate(180%) blur(20px);
backdrop-filter: saturate(180%) blur(20px);
pointer-events: none;
}
/* On a phone-width screen, give the page edges a bit less padding so cards
use more of the available width. */
@media (max-width: 480px) {
.navbar {
padding: 0.6rem 1rem;
padding-top: calc(0.6rem + env(safe-area-inset-top));
}
.container {
padding: 1rem;
/* Was calc(3.5rem + env(safe-area-inset-top)), reserving room for
a fixed navbar -- caught 2026-09-01 while verifying that the
navbar now scrolls away instead (see its own rule). The base
.container rule had been updated but this one hadn't, and since
a real iPhone sits squarely inside this 480px breakpoint, THIS
is the rule that actually takes effect on the device -- the
base fix alone would have left a ~56px empty gap at the top of
every page on the phone. Exactly the sibling-rule gap the
.container.no-navbar comment right below already warns about. */
padding-top: 1rem;
padding-bottom: 4.5rem;
}
.container.no-navbar {
/* Same real bug as the base .container.no-navbar rule above --
this media-query override was ALSO missing
env(safe-area-inset-top), and since a real iPhone falls
squarely inside this max-width: 480px breakpoint, THIS is the
rule that was actually taking effect on the reported device --
the earlier fix to the base rule alone would not have
actually solved anything on a real phone. Found by grepping
for every safe-area-inset usage after fixing the base rule,
specifically to check for exactly this kind of sibling gap. */
padding-top: calc(1rem + env(safe-area-inset-top));
}
}
/* Bottom tab bar -- see base.html for why this replaced a top nav-links
list. `env(safe-area-inset-bottom)` adds extra padding on phones with a
home-indicator gesture bar (notably iPhones) so the tab bar's labels
don't sit underneath it. */
.bottom-nav {
position: fixed;
bottom: 0;
left: 0;
right: 0;
display: flex;
background: var(--color-surface);
border-top: 1px solid var(--color-border);
padding-bottom: env(safe-area-inset-bottom);
z-index: 100;
}
.bottom-nav-item {
flex: 1;
display: flex;
flex-direction: column;
align-items: center;
gap: 0.15rem;
padding: 0.5rem 0 0.4rem;
text-decoration: none;
color: var(--color-text-muted);
font-size: 0.7rem;
}
.bottom-nav-icon-svg {
width: 22px;
height: 22px;
/* No color set here on purpose -- fill="currentColor" on the