/* ============================================================
   SHIFTSIMPLE — BASE (styles/base.css)
   ============================================================
   Reset, document defaults, typography and the themed focus ring. Nothing
   page-specific belongs here. */
  *{box-sizing:border-box;}
  /* Themed fallback focus ring for any interactive element without its own
  explicit focus style (buttons, links, the theme picker's cards, etc.) —
  keeps keyboard focus visible and on-brand across every skin rather than
  relying on the browser default outline, which doesn't track --focus-ring. */
  :focus-visible{outline:2px solid var(--focus-ring);outline-offset:2px;box-shadow:var(--glow);}
  /* html never had its own background-color — only body did. CSS background
  propagation (body -> html/canvas, CSS2.1 14.2) covers ordinary rendering,
  but the canvas area WebKit paints during iOS overscroll/rubber-band bounce
  and dynamic-toolbar show/hide transitions is a distinct paint path that
  does not reliably pick up the propagated color on every WebKit version.
  Setting the color directly on html removes the dependency on propagation
  entirely, so there is no moment where an unpainted (browser-default,
  effectively white) canvas can show through as a "blank" area, regardless
  of how the toolbar/visualViewport transition itself behaves. See
  BLANKSPACE_SCROLL_BUG.md for the investigation that identified this. */
  html{scroll-behavior:smooth;background:var(--paper);}
  body{
    margin:0;
    background:var(--paper);
    color:var(--ink);
    font-family:'IBM Plex Sans', sans-serif;
    -webkit-font-smoothing:antialiased;
  }
  h1,h2,h3,.serif{
    font-family:'Fraunces', serif;
    font-weight:600;
    letter-spacing:-0.01em;
    margin:0;
  }
  .mono{font-family:'IBM Plex Mono', monospace;}
  a{color:inherit;}
  button{font-family:inherit;cursor:pointer;}
  ::selection{background:var(--gold-soft);}
