/* ============================================================================
   pv3 wall — the surface layer for screens nobody touches.

   The wallboards (/ageuknswd, /pooleit, /stirling/*) and the signage screens
   render on Raspberry Pi digital signage, mounted on a wall, viewed from across
   a room, left open for weeks. That is a genuinely different device from the
   laptop pv3-core was drawn for, and four things core does are wrong here:

     background-attachment: fixed   full repaint on a Pi GPU; the worst offender
     backdrop-filter                expensive, and there is nothing to blur
     animation: … infinite          a shimmer that never ends burns CPU forever,
                                    and the fan is audible in a charity office
     :has()                         Chromium 105+; signage boxes are rarely
                                    updated, so this is a compatibility cliff

   None of those are in pv3-core any more except the first two, which this file
   turns off for the wall. There is no pointer here either, so hover states and
   coarse-pointer touch targets are dead weight.

   Load order: tokens.css → pv3-core.css → pv3-wall.css
   Body: class="pv3 pv3-wall"
   ========================================================================== */

/* ---------------------------------------------------------------------------
   THE SURFACE. These three values are the whole light/dark decision.

   The estate moved to one cream-and-forest scheme, and the measured brand data
   supports it: every brand hue sits above the dark-mode lightness band, gold
   carries no text on cream (2.40:1) but reads at 5.21:1 on the dark field, so
   "cream paper, forest bands" is what the palette is actually for.

   What has NOT been checked is a physical 55" screen in a room, because there
   was no screen to look at. If cream turns out to glare, or the room is dim and
   it is too bright, change these three lines — not the components, not the
   markup, and certainly not by reinstating the 2,616 lines of stirling-*.css
   that were retired. Everything below reads its colour from here.
   --------------------------------------------------------------------------- */
body.pv3-wall{
  --wall-canvas: var(--page-1);
  --wall-panel:  var(--paper);
  --wall-ink:    var(--c-ink);
}

/* ---- canvas: flat, unfixed, unfiltered ------------------------------------ */
body.pv3-wall{
  background:var(--wall-canvas);       /* no gradient, no radial, no attachment */
  background-attachment:scroll;
  color:var(--wall-ink);
  min-height:100vh;
  padding:clamp(18px,2.2vw,34px);
  /* A wallboard never scrolls. If content overflows, that is a layout bug to
     see, not something to hide behind a scrollbar. */
  overflow:hidden;
}
.pv3-wall .pv3-ribbon{backdrop-filter:none; background:var(--paper)}

/* ---- nothing here responds to a pointer, because there isn't one ---------- */
.pv3-wall .pv3-card:hover,
.pv3-wall .pv3-btn:hover,
.pv3-wall .pv3-hcard:hover{transform:none; box-shadow:var(--shadow-card); border-color:var(--hair)}
.pv3-wall .pv3-btn,
.pv3-wall .pv3-tab{min-height:0}

/* ---- no animation that never ends -----------------------------------------
   The entrance choreography is fine — it runs once when the page loads. The
   skeleton shimmer is not: these pages are opened and then left, so an infinite
   keyframe is a permanent CPU cost for a placeholder nobody is watching. It
   becomes a flat block that still reads as "not loaded yet". */
.pv3-wall .pv3-sk::after{display:none}
.pv3-wall .pv3-sk{background:var(--page-2)}
.pv3-wall .lds-skeleton{background:var(--page-2); animation:none}

/* ---- read from across a room ----------------------------------------------
   Everything steps up roughly one size. The figures step up more, because at
   four metres the number is the only thing anyone actually reads. */
.pv3-wall{font-size:18px}
.pv3-wall .pv3-title{font-size:clamp(38px,4vw,62px)}
.pv3-wall .pv3-subtitle{font-size:19px}
.pv3-wall .pv3-card-head h2{font-size:26px}
.pv3-wall .pv3-stat-label{font-size:13px; letter-spacing:.12em}
.pv3-wall .pv3-stat-value{font-size:clamp(34px,3.4vw,52px)}
.pv3-wall .pv3-fig-label{font-size:13px}
.pv3-wall .pv3-fig-value{font-size:clamp(36px,3.8vw,58px)}
.pv3-wall .pv3-note-soft{font-size:15px}
.pv3-wall .pv3-status,.pv3-wall .pv3-pill{font-size:15px; padding:7px 14px}

/* Panels sit a little tighter and lift a little less: at distance the shadow
   reads as blur, not depth. */
.pv3-wall .pv3-card{padding:22px 24px; box-shadow:var(--shadow-1)}
.pv3-wall .pv3-deck{gap:18px}

/* ---- the wall grid --------------------------------------------------------
   A fixed screen has a known aspect ratio and no scroll, so the layout is a
   grid that fills it rather than a column that grows. */
.pv3-wall-grid{display:grid; grid-template-columns:2fr 1fr; gap:18px; align-items:start}
.pv3-wall-stack{display:grid; gap:18px}
@media (max-width:1100px){ .pv3-wall-grid{grid-template-columns:1fr} }

/* ---- the stamp: "updated at", the one thing that proves the screen is alive
   A wallboard showing yesterday's numbers looks exactly like a wallboard
   showing today's, so the timestamp is not decoration. */
.pv3-wall-stamp{display:inline-flex; align-items:baseline; gap:10px; margin-top:6px}
.pv3-wall-stamp .lbl{font:600 12px/1 var(--f-body); letter-spacing:.14em;
  text-transform:uppercase; color:var(--c-ink-soft)}
.pv3-wall-stamp .val{font:600 18px/1 var(--f-head); color:var(--c-forest-d);
  font-variant-numeric:tabular-nums}
.pv3-wall-stamp.is-stale .val{color:var(--status-alert-ink)}

/* ---- print is meaningless on a wall --------------------------------------- */
@media print{ .pv3-wall{display:none} }

/* ---- the fixed stage --------------------------------------------------------
   A wallboard runs on a Pi driving an unknown panel, and a fluid layout is
   therefore untestable — it will be *some* size on the wall and the only way to
   find out whether the last card fell off the bottom is to stand in front of it.

   So the page is authored at exactly 1920x1080 and pv3-stage.js scales that to
   whatever viewport it gets. The useful consequence: a desktop browser at any
   window size shows exactly what the wall shows, because it is the same stage
   under a different scale factor.

   `transform-origin: top left` because the script computes its own centring
   offset — letting the browser centre as well would double the translation.
   ------------------------------------------------------------------------- */
body.pv3-staged{
  padding:0;
  overflow:hidden;
  /* Letterbox. The stage is centred inside this, and the bands are canvas
     rather than black so a slightly-wrong aspect ratio reads as margin. */
  background:var(--wall-canvas);
}
.pv3-stage{
  position:absolute; top:0; left:0;
  transform-origin:top left;
  overflow:hidden;
  background:var(--wall-canvas);
  /* Deliberately NO will-change: it pins a compositor layer the size of the
     stage for the life of the page, and this device has little VRAM to spare
     for a transform that changes only on resize. */
}
.pv3-stage > *{ padding:clamp(18px,2.2vw,34px); box-sizing:border-box; min-height:100% }

/* ?stage=debug — the numbers an author cannot get by looking at a photo of a
   screen. "OVERFLOWS by 240px" is the answer to "why is the bottom card
   missing", which is otherwise a silent failure on a wall. */
.pv3-stage-debug{
  position:fixed; right:10px; bottom:10px; z-index:2147483646;
  font:600 12px/1.3 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;
  background:var(--c-forest-d); color:var(--c-cream);
  padding:7px 11px; border-radius:8px; pointer-events:none;
}
.pv3-stage-debug.is-overflow{ background:var(--status-alert-ink) }