/* ==========================================================================
   2D Football Wars — responsive.css
   Orientation policy, input-modality adjustments and the few places where a
   viewport genuinely needs different rules.

   Layout note: sizes across the rest of the stylesheets are multiples of the
   stage unit (`--u`, see variables.css), so shrinking the window shrinks the
   whole interface uniformly. That means this file deliberately contains *no*
   "shrink this on mobile" or "hide that on mobile" rules — a phone held in
   landscape gets the same components, in the same order and the same
   positions, as a desktop; only the scale differs.
   ========================================================================== */

/* ==========================================================================
   LANDSCAPE LOCK
   The pitch is a 16:9 world, the HUD is anchored to its four corners and the
   touch controls sit under two thumbs at the bottom edge. None of that has a
   portrait equivalent, so the game does not run in portrait: it is paused and
   held behind a full-screen prompt until the device is turned.

   `html.portrait-block` is set by main.js, which is the authority (it also
   pauses the match and stops the platform's gameplay session). The media
   query below is the no-JS fallback and keeps the block working if the module
   fails to load.
   ========================================================================== */

#rotate-hint {
  position: fixed;
  inset: 0;
  z-index: 100;
  display: none;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: var(--sp-3);
  background:
    radial-gradient(120% 90% at 50% 0%, #12204a 0%, transparent 55%),
    radial-gradient(90% 70% at 50% 115%, #0c2b1c 0%, transparent 60%),
    var(--c-bg-0);
  text-align: center;
  padding: max(8%, var(--sp-5));
  padding-top: max(8%, calc(var(--safe-t) + var(--sp-4)));
  padding-bottom: max(8%, calc(var(--safe-b) + var(--sp-4)));
}
#rotate-hint .rotate-icon {
  font-size: min(22vw, 22vh);
  line-height: 1;
  animation: rotate-wiggle 1.8s ease-in-out infinite;
  filter: drop-shadow(0 12px 30px rgba(0, 0, 0, 0.6));
}
@keyframes rotate-wiggle {
  0%, 55%, 100% { transform: rotate(0deg); }
  75%, 92% { transform: rotate(-90deg); }
}
#rotate-hint h2 {
  font-family: var(--font-display);
  text-transform: uppercase;
  letter-spacing: var(--ls-wide);
  font-size: min(6.5vw, 1.6rem);
  background: linear-gradient(180deg, #ffffff 20%, #9cc8ff 60%, #38e08c 100%);
  -webkit-background-clip: text;
  background-clip: text;
  color: transparent;
}
#rotate-hint p {
  color: var(--c-text-dim);
  font-size: min(4vw, 0.95rem);
  max-width: 30ch;
}
#rotate-hint .rotate-cta {
  margin-top: var(--sp-2);
  min-height: var(--tap-min);
  padding: 0.7em 1.8em;
  font-size: min(4vw, 0.95rem);
}
/* Only offered where the browser can actually honour it (see main.js). */
#rotate-hint .rotate-cta[hidden] { display: none; }

/* No-JS fallback. A media query can only see this document's box, which
   inside an embed is the iframe rather than the device — so it is superseded
   the moment main.js takes over (`html.js-orientation`), which reads the
   real device orientation instead. */
@media (orientation: portrait) and (pointer: coarse),
       (orientation: portrait) and (max-width: 900px) {
  #rotate-hint { display: flex; }
}
html.js-orientation #rotate-hint { display: none; }
html.js-orientation.portrait-block #rotate-hint,
html.portrait-block #rotate-hint { display: flex; }
/* Nothing behind the prompt may be reached, focused or scrolled. */
html.portrait-block #stage { visibility: hidden; }

/* ==========================================================================
   INPUT MODALITY

   Touch targets are grown by *hit area*, never by box size: enlarging the
   boxes would move everything around them and the mobile layout would stop
   matching desktop. So each control keeps its drawn size and gains an
   invisible overlay that reaches the 44px minimum.

   Where a control sits in open space (the pause button, the touch pads) the
   overlay can expand freely. Where controls are packed together (menu rows)
   it expands only into the gap, because two overlapping hit areas are worse
   than one small one. The power slots are handled in ui.js instead — they
   clip their own overflow, so their panel does the nearest-slot match.
   ========================================================================== */

@media (pointer: coarse) {
  /* Open space: take the full 44px. `2.4em` is the button's drawn size and
     its `em` is --fs-small, so the maths below is exact at any scale. */
  #pause-btn::before {
    content: "";
    position: absolute;
    inset: min(0px, calc((2.4em - var(--tap-min)) / 2));
  }

  /* Packed controls: reach into the surrounding gap and no further, so two
     neighbours never claim the same pixel. (`.btn` is absent by necessity —
     it clips its own overflow for the hover shine, which would swallow the
     overlay. Its boxes are the widest controls in the menu anyway.) */
  .rail-btn,
  .segmented button,
  .tabs button,
  .bind-key,
  .stadium-nav { position: relative; }
  .rail-btn::before,
  .segmented button::before,
  .tabs button::before,
  .bind-key::before,
  .stadium-nav::before {
    content: "";
    position: absolute;
    inset: calc(var(--sp-2) / -2);
  }

  /* Hover affordances never fire on touch and only leave sticky states. */
  .btn:hover,
  .mode-card:hover,
  .arena-card:hover,
  .power-card:hover,
  .rail-btn:hover { transform: none; }
}

/* Touch devices cannot hover, so the power tooltips are dead weight; the
   power browser in the menu carries the same information. */
@media (hover: none) {
  .power-slot .p-tip { display: none; }
}

/* ==========================================================================
   VIEWPORT EXCEPTIONS
   ========================================================================== */

/* Very small stages: the scrollable menu bodies are the only thing that can
   run out of room, because their content count is fixed while their box
   scales. Give them the rest of the panel rather than a fixed fraction. */
@media (max-width: 560px), (max-height: 380px) {
  .settings-body { min-height: 0; max-height: 100%; }
  .howto-columns,
  .achievements-list,
  .mode-grid { max-height: 100%; }
}

/* Desktop windows narrower than the stage's own reference width still get the
   full layout — the stage unit has already scaled it. Nothing to do here.   */
