App.css

/* Screens that are not the map still need the tab bar pinned and their own
   content scrollable underneath it, which the map screen gets from its own
   grid (chrome.css).

   `height`, not `min-height`: a floor lets the column grow past the viewport
   whenever the content does, and a flex item that is already as tall as its
   content never scrolls - so the page scrolled instead and carried the tab bar
   away below the fold. Settings is long enough to do that on any phone, which
   left the only navigation off-screen until you scrolled to the bottom of it.
   A fixed height is what makes the overflow below land on the content. */
.app__screen {
  height: 100svh;
  display: flex;
  flex-direction: column;
  background: var(--bg-page);
}

.app__screen > :first-child {
  flex: 1;
  /* Flex items floor at their content height by default; the tab bar only
     stays put if this one is allowed to be shorter than what is inside it. */
  min-height: 0;
  overflow-y: auto;
  /* The containing block for anything a screen positions absolutely. Without
     a positioned ancestor those boxes resolve against the document, and
     overflow cannot clip what it does not contain - the pickers' hidden
     radios landed past 100svh and handed the PAGE a second scrollbar, which
     scrolled the whole frame, tab bar and all, up into blank paper (#631).
     Positioned, this pane scrolls and clips them with the content they
     belong to. */
  position: relative;
}

/* First run used to have its own frame here - .app__entry, .app__entry-map and
   .app__entry-attribution - holding a second MapView behind the steps. #721
   removed all three: the map screen itself is the backdrop now, hidden down to
   its canvas by chrome.css's .map-screen--entering, so there is one map instead
   of two and nothing here to lay out. */

.app__notice {
  margin: 0;
  padding: var(--space-3, 12px) var(--space-4, 16px);
  background: var(--surface-warning);
  color: var(--fg-1);
  font-size: 0.875rem;
}

/* There was an .app__update / .app__update-action pair here for a "a new
   version is ready - tap to reload" banner. Nothing ever rendered it, and its
   own comment described the opposite of what shipped: it said the hiker
   chooses when to swap versions, while vite.config.ts uses `autoUpdate` and
   lib/useAppUpdate.ts reloads on its own once the new worker takes control.
   Deliberately so - the previous `prompt` setting had nothing to supply the
   prompt, which is the bug that whole change set out to fix. Removed rather
   than left as a style for a banner that does not exist and a decision that
   was reversed. */