/* The shell belongs to the VISUAL viewport while a keyboard is open.
 *
 * Operator report 2026-09-22, iPhone: focusing the composer pushed the input
 * up out of sight and took the top bar with it — "if I drag down I do see it".
 * That is the layout viewport scrolling under a keyboard that the layout
 * viewport does not know about. `height: 100dvh` does not help here: dvh
 * tracks browser chrome, not the keyboard, so the shell stays full height and
 * everything below the fold goes behind the keys.
 *
 * runtime/visual-viewport.js already publishes the visual viewport's height,
 * top and bottom, and flags [data-visual-keyboard-open]. This is the shell
 * consuming them — the machinery existed, the app shell was not using it.
 *
 * Deliberately NOT a transform: a transformed body becomes the containing
 * block for every position:fixed descendant, which would move the sheets,
 * popovers and menus that are anchored to the viewport on purpose.
 */

html[data-visual-keyboard-open] body {
  /* The visible box, not the layout one. overflow:hidden is already on body
     (design-system/foundation.css), so this makes the shell end where the
     keyboard begins instead of running underneath it. */
  height: var(--cc-visual-viewport-height, 100dvh);
  min-height: 0;
}

/* Safari can still leave the layout viewport offset for a frame before
   settleLayoutViewport() puts it back; anchoring the shell to the visual
   viewport's top means the header is never the thing that scrolls away. */
html[data-visual-keyboard-open] body > .topbar {
  position: sticky;
  top: 0;
  z-index: var(--cc-z-topbar, 40);
}