/* Tailwind's min-h-screen class (on in index.html) compiles to min-height: 100vh. On iOS Safari, 100vh is the "large viewport" value — it assumes the address bar is hidden, so it's taller than the visible area whenever the bar is actually showing. resizeCanvas() (js/main.js) sizes the canvas off window.innerHeight instead, which always reflects the real, currently-visible viewport — so on iOS, body ends up taller than the canvas by exactly the address-bar's height, and centering that extra space top/bottom left a black gap above the board (confirmed live via a user screenshot). dvh (dynamic viewport height) tracks the same real visible viewport window.innerHeight does, closing that gap; `body.min-h-screen` (element+class) is needed for specificity to beat Tailwind's own `.min-h-screen` rule — a bare `body {}` rule here would lose to it regardless of source order. Browsers without dvh support ignore the second declaration and keep the 100vh fallback. */ body.min-h-screen { min-height: 100vh; min-height: 100dvh; } /* Landscape-only gate — see js/utils/orientationGate.js. Shown/hidden via inline style.display from JS (checks the actual viewport aspect ratio), not a media query, so the base rule here just establishes the covering layout; display:none is the resting state until JS decides otherwise. */ #orientationGate { position: fixed; inset: 0; z-index: 9999; display: none; flex-direction: column; align-items: center; justify-content: center; background: #0f172a; color: #fff; text-align: center; padding: 24px; } #orientationGate .rotate-icon { font-size: 3rem; margin-bottom: 1rem; } /* Power-LED dot in the top-left corner doubles as a live mouse-escape-danger meter, not just a static power light: GameScreen.updateEscapeDangerIndicator() sets `document.body.dataset.mouseDanger` ('low'/'medium'/'high', based on the mouse's distance to the nearest escape hole) every frame regardless of device — harmless on desktop since these rules are gated behind the same `pointer: coarse` check already used for the touch controls, so the LED only ever shows on an actual touch device. (The handheld-console bezel border that used to frame the viewport here was removed — read as an unwanted grey border on-device rather than a bevel.) */ @media (pointer: coarse) { body::before { content: ''; position: fixed; top: 15px; left: 20px; width: 8px; height: 8px; border-radius: 50%; background: radial-gradient(circle at 35% 30%, #9bff9f, #1ec83f 75%); box-shadow: 0 0 4px rgba(40, 255, 80, 0.7); z-index: 9991; pointer-events: none; transition: background 0.2s ease, box-shadow 0.2s ease; } body[data-mouse-danger="medium"]::before { background: radial-gradient(circle at 35% 30%, #fff59b, #c8961e 75%); box-shadow: 0 0 4px rgba(255, 200, 40, 0.75); } body[data-mouse-danger="high"]::before { background: radial-gradient(circle at 35% 30%, #ff9b9b, #c81e1e 75%); box-shadow: 0 0 5px rgba(255, 40, 40, 0.85); } } /* On-screen D-pad (movement) — see js/utils/touchControls.js. Anchored within the left gutter (the empty space between the viewport frame and the canvas's left edge), centered both horizontally and vertically *within that gutter's own footprint* rather than at a fixed offset from the viewport edge. Horizontal centering depends on the canvas's actual runtime position (its width isn't fixed — see resizeCanvas() in js/main.js), so `left` here is just a fallback; touchControls.js sets the real value from the canvas's bounding rect on load/resize/ orientationchange, using the same transform: translate(-50%, -50%) this rule establishes. Vertical centering (top: 50%) doesn't need that same JS treatment — the gutter spans the full viewport height regardless of where the canvas sits vertically, so viewport-center is already correct. Hidden by default; only shown when both the pointer is coarse (touch) and gameplay is actually running (GameScreen adds .in-game to in init() and removes it in cleanup()) — this keeps desktop play uncluttered and keeps the control off the setup screen. A hand-tuned CSS approximation of a supplied reference photo (rounded- corner + clip-path shapes, gradients, shadows) read as amateurish next to the actual photo — CSS shading can't reproduce a real render's curvature and material look. So this now uses the reference image itself: `assets/dpad_cross.png`, cropped tightly from the full- resolution (1672x941) source down to just the cross plus a small margin, resized to 320x320. `#dpad` just displays that image; there's no drawn disc, gradient, or button shape here anymore, which is also why there's no circular rim — the reference has none. The four `