/* The waiting room. Same sky, same type, one page: the empathy note and the
   arcade. Layout only; the site's tokens do the identity. */

.waiting-body {
  min-height: 100vh;
  color: #ffffff;
  background: transparent;
}

.waiting-top {
  display: flex;
  align-items: center;
  justify-content: space-between;
  padding: 22px clamp(20px, 4vw, 44px);
}

/* Both dimensions, not height plus auto: the mark is a fixed 1631:281 and
   letting the width be computed is what let the header and the footer drift
   out of proportion with each other. */
.waiting-top img { width: 151px; height: 26px; opacity: 0.92; }

.waiting-back {
  font-size: 14px;
  color: rgba(233, 240, 250, 0.8);
  padding: 8px 14px;
  border: 1px solid rgba(255, 255, 255, 0.16);
  border-radius: 999px;
  transition: border-color 200ms var(--ease), color 200ms var(--ease);
}

.waiting-back:hover { border-color: rgba(184, 231, 106, 0.6); color: #ffffff; }

.waiting-main {
  max-width: 1000px;
  margin: 0 auto;
  padding: clamp(16px, 3vw, 40px) clamp(20px, 4vw, 44px) 80px;
}

.waiting-note h1 {
  color: #ffffff;
  margin-bottom: 22px;
}

/* Solid, not clipped. This was a gradient painted through the glyphs with
   `color: transparent`, which is the same pattern that was removed from the
   hero: it has no fallback, so on anything that does not support
   background-clip: text the line does not go plain — it goes invisible. That is
   an acceptable risk on decoration and not on this line, which is the whole
   emotional point of the page.

   It is also what made this block impossible to measure. Checking the ground
   behind the headline means ghosting the type and photographing what is left,
   and ghosting a clipped fill reveals the gradient underneath it instead of
   hiding it: the "brightest pixel behind the headline" turned out to be the
   word "Yours". Three rounds of widening a reading pool went into chasing that
   before the browser was asked what was actually at the pixel. */
.waiting-note h1 em {
  font-style: normal;
  color: #a3e635;
}

.waiting-copy {
  max-width: 720px;
  margin: 0 0 16px;
  line-height: 1.75;
  color: rgba(233, 240, 250, 0.82);
}

.waiting-game { margin-top: 48px; }

.game-head h2 { color: #ffffff; margin-bottom: 6px; }
.game-head .sub { color: rgba(233, 240, 250, 0.7); margin: 0 0 18px; }

.game-shell {
  position: relative;
  border: 1px solid rgba(255, 255, 255, 0.14);
  border-radius: 18px;
  background: rgba(3, 8, 18, 0.72);
  backdrop-filter: blur(6px);
  -webkit-backdrop-filter: blur(6px);
  overflow: hidden;
}

.game-shell canvas {
  display: block;
  width: 100%;
  height: auto;
  /* pan-y, not none. With none, a finger that lands anywhere on the game
     cannot scroll the page, and on a phone the game is most of the screen:
     the page simply refuses to move and reads as broken. pan-y hands vertical
     swipes back to the document and keeps horizontal drags for the cannon,
     which is the only axis the cannon has. */
  touch-action: pan-y;
  cursor: crosshair;
  /* A grey flash on every shot, on Android, reading as lag that was not
     there. Firing is drawn on the canvas; the browser's tap feedback is not
     wanted on top of it. */
  -webkit-tap-highlight-color: transparent;
  -webkit-user-select: none;
  user-select: none;
}

.game-hud {
  position: absolute;
  /* Nothing here is for touching, and without this it was: the HUD spans the
     full width of the top of the playfield, so every tap in that strip hit a
     div rather than the canvas. Those taps did not fire, and because a plain
     div carries no touch-action they were read as an ordinary double tap,
     which is the page zooming while the player is shooting. */
  pointer-events: none;
  top: 12px;
  left: 16px;
  right: 16px;
  display: flex;
  justify-content: space-between;
  gap: 14px;
  font-family: var(--mono);
  font-size: 15px;
  color: #a3e635;
  pointer-events: none;
  text-shadow: 0 0 8px rgba(163, 230, 53, 0.6);
}

#hudBest { color: rgba(233, 240, 250, 0.6); text-shadow: none; }
#hudLives { color: #f87171; letter-spacing: 4px; text-shadow: 0 0 8px rgba(248, 113, 113, 0.5); }

.game-overlay {
  position: absolute;
  inset: 0;
  display: grid;
  place-items: center;
  text-align: center;
  padding: 30px;
  background: rgba(3, 8, 18, 0.82);
  backdrop-filter: blur(4px);
  -webkit-backdrop-filter: blur(4px);
}

.game-overlay[hidden] { display: none; }

.game-overlay h3 { color: #ffffff; font-size: 26px; margin: 0 0 12px; }
.game-overlay p { max-width: 520px; margin: 0 auto 14px; color: rgba(233, 240, 250, 0.8); line-height: 1.65; }
.overlay-keys { font-size: 13px; color: rgba(233, 240, 250, 0.6); }

.game-foot {
  margin-top: 18px;
  font-size: 14px;
  line-height: 1.7;
  color: rgba(233, 240, 250, 0.7);
}

.game-foot a { color: #a3e635; text-decoration: underline; text-underline-offset: 3px; }

@media (max-width: 700px) {
  .waiting-top img { width: 128px; height: 22px; }
  .game-overlay h3 { font-size: 21px; }

  /* The canvas keeps its 900x640 drawing surface and is merely displayed
     taller: on a 390px phone the width-driven height came out at 247px, a
     letterbox the cannon and the falling blockers had to share. Height is
     driven by the viewport instead, so the playfield is worth aiming at. */
  .game-shell canvas {
    height: min(58vh, 420px);
    width: 100%;
    object-fit: contain;
  }

}

/* ---------- controls, chosen by what the reader is holding ---------- */

/* This used to switch on `max-width: 700px`, which is a proxy for a phone and
   a bad one in both directions: a touch laptop and a tablet in landscape were
   told to use a mouse and arrow keys they do not have, and a desktop window
   dragged narrow was told to drag with a finger. `pointer: coarse` asks the
   actual question. The owner's complaint that nobody knows how to play starts
   here, because for a good number of readers the instructions were for
   somebody else's machine. */
.game-keys {
  margin: 10px 0 0;
  text-align: center;
  font-size: 13px;
  line-height: 1.6;
  color: rgba(233, 240, 250, 0.62);
}

.game-keys.for-touch,
.overlay-keys.for-touch,
.game-fire { display: none; }

@media (pointer: coarse) {
  .game-keys.for-pointer,
  .overlay-keys.for-pointer { display: none; }
  .game-keys.for-touch,
  .overlay-keys.for-touch { display: block; }

  /* Big enough to hit without looking, which is the point: the eyes are on
     the falling blockers, not on the button. */
  .game-fire {
    display: block;
    width: 100%;
    margin: 12px 0 0;
    padding: 18px 20px;
    border: 1px solid rgba(184, 231, 106, 0.55);
    border-radius: 14px;
    background: rgba(184, 231, 106, 0.14);
    color: #d9f99d;
    font-family: var(--mono, ui-monospace, monospace);
    font-size: 15px;
    font-weight: 700;
    letter-spacing: 0.24em;
    /* manipulation, not pan-y: this one is only ever tapped, and manipulation
       is the value that tells every browser, including the one that ignores
       the others, that a second tap here is not a request to zoom. */
    touch-action: manipulation;
    -webkit-user-select: none;
    user-select: none;
    -webkit-tap-highlight-color: transparent;
  }

  .game-fire:active {
    background: rgba(184, 231, 106, 0.28);
    border-color: rgba(184, 231, 106, 0.8);
  }
}


/* ---------- the copy has to survive the field ---------- */

/* This page inherits the site's sky but never got the reading pools that came
   with it, and measuring the two blocks gave opposite answers to the one my eye
   gave. The body copy is fine: worst-case ground under it is 11.15:1, because
   it is small type over a wide area and the bright cores mostly miss it.

   The headline is not. Its worst case measured 1.23:1 — an orb sitting directly
   behind a letter at nearly full white, on the largest type on the page. That
   is not a legibility margin, it is a word disappearing.

   Same treatment as the bands on the main page: an ellipse of the page's own
   dark, sized to the block, feathered to nothing well before its own edge, so
   the orbs either side of the column are untouched. */
.waiting-note,
.waiting-arcade > h2,
.waiting-arcade > p {
  position: relative;
}

.waiting-note::before,
.waiting-arcade > h2::before {
  content: "";
  position: absolute;
  /* Wide enough that the feather happens outside the text, not across it.

     Two earlier attempts both failed the same way from opposite ends. Anchored
     left at 34%, like the bands' pool, the last words of the headline sat past
     the dense zone and the worst case stayed at 1.25:1. Centred, the fade moved
     to the edges and the brightest pixel turned up at local x=1 — the very
     first letter. A pool whose gradient falls off anywhere inside the block it
     is protecting will always leave one end exposed; which end just depends on
     where it is anchored.

     So the box is 36% wider than the block and the gradient holds full density
     out to 45% of that box, which is past the block's own edge in both
     directions. Everything the reader reads sits on the plateau; the ramp is
     entirely in the margin. */
  inset: -70px -18%;
  z-index: -1;
  pointer-events: none;
  background: radial-gradient(
    120% 75% at 50% 50%,
    rgba(3, 8, 18, 0.84) 0%,
    rgba(3, 8, 18, 0.80) 45%,
    rgba(3, 8, 18, 0.55) 62%,
    rgba(3, 8, 18, 0.22) 80%,
    rgba(3, 8, 18, 0) 100%
  );
}

/* A phone is nearly all reading area, so a pool per block adds up to the
   band-wide veil this approach exists to avoid. */
@media (max-width: 768px) {
  .waiting-note::before,
  .waiting-arcade > h2::before { display: none; }
}