/* ============================================================
   mobile.css – Touch-/Mobile-spezifische Anpassungen für SCOPE
   (siehe MOBILE_PLAN.md, WP1ff.). Wird ZUSÄTZLICH zu style.css/
   tutorial.css geladen. Alle Regeln sind auf [data-device="touch"]
   gescoped (gesetzt von device.js) - im Desktop-Modus bleibt das
   bestehende Layout unverändert.
   ============================================================ */

/* ── Textauswahl auf Touch deaktivieren ──────────────────────
   Julians Testfund: langes Antippen von Text loeste die native iOS/
   Android-Textauswahl aus (blaue Markierung, Kopieren-Menue) - waehrend
   des Spielens nie gewollt, es gibt nichts zu kopieren. Bewusst NICHT
   in den Rotations-Media-Query gepackt (siehe unten), da das Problem
   unabhaengig von der erzwungenen Querformat-Situation auftritt (auch
   z.B. wenn ein Tablet bereits physisch im Querformat gehalten wird).
   Formularfelder (input/textarea) sind davon nicht betroffen - dort
   bleibt Texteingabe/-auswahl unabhaengig von einem geerbten
   user-select:none auf einem Vorfahren moeglich.
*/
html[data-device="touch"] {
  -webkit-touch-callout: none;
  -webkit-user-select: none;
  user-select: none;
}

/* ── Sichtbare Querformat-Masse als Custom Properties ─────────────────
   Julians Testfund (2026-09-02): dreht man das Handy zusaetzlich PHYSISCH
   ins Querformat, "springt" das Layout ploetzlich zurueck in ein enges/
   hohes Default-Aussehen. Ursache: der Rotationstrick greift nur unter
   "@media (orientation: portrait)" (im echten Querformat braucht es ihn ja
   nicht). Die WEITEREN Touch-Regeln unten (Panel-Breite, Dropdown-Hoehe)
   nutzten aber unbedingt vh/vw mit der Annahme "vh = sichtbare Breite" -
   das stimmt nur, SOLANGE der Rotationstrick tatsaechlich aktiv ist (Hoch-
   format-Haltung). Haelt man das Geraet bereits physisch quer, ist ohne
   Rotationstrick vw ganz normal die sichtbare Breite, nicht vh - dieselbe
   feste Formel ergab dann das genaue Gegenteil des gewuenschten Layouts.
   Fix: zwei Custom Properties, die JE NACH tatsaechlicher Orientierung auf
   die richtige physische Achse zeigen - alles unten benutzt nur noch
   var(--landscape-w)/var(--landscape-h), nie direkt vw/vh. */
html[data-device="touch"] {
  --landscape-w: 100dvw;
  --landscape-h: 100dvh;
}
@media (orientation: portrait) {
  html[data-device="touch"] {
    --landscape-w: 100dvh;
    --landscape-h: 100dvw;
  }
}

/* ── Notch/Dynamic-Island/Home-Indicator bei PHYSISCH bereits gehaltenem
   Querformat (2026-09-23) ────────────────────────────────────────────────
   Bislang war die Notch-/Home-Indicator-Pufferung (siehe die grosse
   @media(orientation:portrait)-Regel unten) NUR fuer den Rotationstrick-Fall
   definiert - also nur, wenn das Geraet physisch im Hochformat gehalten und
   die Drehung per CSS simuliert wird. Julians Testfund (2026-09-23): auf
   seinem echten iPhone haelt er das Geraet zum Spielen laengst physisch quer
   (wofuer der Rotationstrick gar nicht erst greift, siehe die "IMMER im
   Querformat, unabhaengig von der Haltung"-Anforderung oben) - fuer GENAU
   diesen Fall gab es bislang ueberhaupt keinen Puffer, keinen dvh-Fix,
   nichts, obwohl es vermutlich die haeufigere Haltung fuer ein Querformat-
   Spiel ist. Kein Rotations-Mapping noetig wie im anderen Fall - die vier
   env(safe-area-inset-*)-Werte entsprechen hier direkt den vier CSS-Seiten.

   WICHTIGE KORREKTUR, real im Browser-Pane per getBoundingClientRect()
   verifiziert (nicht nur theoretisch hergeleitet - siehe die Lehre aus
   project_geogame_mobile_plan dazu, Claudes eigener Geometrie-Herleitung
   hier grundsaetzlich zu misstrauen): Padding auf body wirkt NUR auf
   normal-Flow-Nachfahren. #start-screen, alle .legal-modal (inkl. dieses
   Vollbild-Popups), #lang-screen, #tutorial-info-screen, #results-screen,
   #image-preview-modal & #familiarity-gallery-screen sind aber
   position:fixed - und selbst mit einem transform auf body (das einen
   "containing block" fuer sie erzeugt) bezieht sich ihr inset:0 auf dessen
   PADDING-BOX, nicht die Content-Box, spannt sich also trotzdem bis an den
   ausseren Rand auf. Deshalb hier stattdessen direkt: die betroffenen
   fixed-Vollbild-Screens selbst bekommen inset-Werte ungleich 0 (siehe
   Regel direkt danach) - das umgeht die containing-block-Problematik
   komplett, da fixed ohne transformierten Vorfahren ganz normal gegen den
   Viewport aufloest. Der Transform-Versuch auf body wurde deshalb wieder
   entfernt (siehe Git-Historie), body-Padding bleibt trotzdem stehen, weil
   es fuer normal-Flow-Inhalte (z. B. #topbar/#sidebar-right im Spiel
   selbst, siehe die "SCOPE-Titel abgeschnitten"-Meldung) weiterhin korrekt
   und noetig ist. */
@media (orientation: landscape) {
  html[data-device="touch"] body {
    height: 100dvh;
    box-sizing: border-box;
    /* Oben/unten schlanker als links/rechts (Julians Wunsch 2026-09-23,
       um dem Satellitenbild mehr Hoehe zu geben - das Bild wird rein ueber
       die verfuegbare Hoehe skaliert, siehe #stage{height:100%;aspect-
       ratio:4/3}, jeder gesparte Pixel oben/unten kommt ihm direkt zugute).
       Nicht auf 0 gesetzt, wie Julian ausdruecklich wollte: Notch/Dynamic-
       Island sitzt im echten Querformat zwar so gut wie nie oben (sondern
       links/rechts, je nach Drehrichtung), aber ein kleiner Puffer bleibt
       als Sicherheitsnetz. Links/rechts bleiben bei 24px, da dort im
       Querformat die Dynamic Island/der Notch tatsaechlich landen kann. */
    padding-top: max(10px, env(safe-area-inset-top));
    padding-right: max(24px, env(safe-area-inset-right));
    padding-bottom: max(10px, env(safe-area-inset-bottom));
    padding-left: max(24px, env(safe-area-inset-left));
  }
  html[data-device="touch"] #start-screen,
  html[data-device="touch"] .legal-modal,
  html[data-device="touch"] #lang-screen,
  html[data-device="touch"] #tutorial-info-screen,
  html[data-device="touch"] #results-screen,
  html[data-device="touch"] #image-preview-modal,
  html[data-device="touch"] #familiarity-gallery-screen {
    top: max(10px, env(safe-area-inset-top));
    right: max(24px, env(safe-area-inset-right));
    bottom: max(10px, env(safe-area-inset-bottom));
    left: max(24px, env(safe-area-inset-left));
  }
}

/* ── Erzwungenes Querformat ──────────────────────────────────
   Julians ausdrücklicher Wunsch: die Anwendung läuft auf Touch-
   Geräten IMMER im Querformat, unabhängig davon, wie das Gerät
   gerade physisch gehalten wird - kein "Bitte drehen"-Hinweis,
   der auf Rotation wartet. screen.orientation.lock() wäre die
   "sauberere" API, funktioniert aber nur im Fullscreen-Modus auf
   Android Chrome und gar nicht auf iOS Safari - der CSS-Trick
   unten ist der einzige plattformübergreifend zuverlässige Weg.

   Prinzip: <body> wird mit vertauschter Breite/Höhe (100vh/100vw)
   positioniert und um 90° um seine eigene obere linke Ecke gedreht;
   "left:100%" (= volle Viewport-Breite bei position:fixed) schiebt
   die gedrehte Box exakt auf die Viewport-Fläche. Nachweis der
   Eckpunkt-Transformation siehe MOBILE_PLAN.md-Kommentar/Commit.
   Nebeneffekt (gewünscht): ein transform auf einem Vorfahren macht
   ihn zum Containing Block für position:fixed-Nachfahren (Modals,
   Banner, Overlays) - die bleiben dadurch weiterhin korrekt an der
   sichtbaren Fläche "fixiert", da body's gedrehte Box exakt die
   Viewport-Fläche deckt.

   Bekannte Einschränkung: vh/vw-Einheiten AUF NACHFAHREN (z. B.
   Modal-Breiten in style.css/tutorial.css) beziehen sich weiterhin
   auf den echten, ungedrehten Viewport, nicht auf die gedrehte
   Darstellung - kann einzelne Modals im Querformat etwas knapper
   bemessen wirken lassen als optimal. Bei Bedarf in WP3 gezielt
   nachschärfen, keine grundsätzliche Funktionsstörung.

   WP3-Fix (2026-09-02, Julians Testfund auf echtem iPhone): zwei
   verwandte Probleme durch die feste Safari-Chrome-Annahme von vh/vw
   und dadurch, dass praktisch KEINE Pufferzone zu den physischen
   Bildschirmraendern bestand:
   1. "Safari-UI ueberlappt das Spiel" - klassischer iOS-Safari-Bug:
      100vh/100vw beziehen sich auf die GROESSTMOEGLICHE Ansicht (Chrome
      eingeklappt), nicht auf die aktuell sichtbare Flaeche. Wenn Safaris
      Adressleiste/Toolbar ausgeklappt ist, ragt unsere exakt 100vh/100vw
      grosse, feste Box dadurch teilweise UNTER Safaris eigene UI - siehe
      https://developer.mozilla.org/en-US/docs/Web/CSS/length#dvh. Fix:
      dvh/dvw (dynamic viewport units, seit iOS 15.4) statt vh/vw - diese
      verfolgen die tatsaechlich sichtbare Flaeche live mit.
   2. "Versehentliches Oeffnen der Menueleiste beim Wischen vom unteren
      Rand" - der Rotationstrick bildet den CSS-oben/unten/links/rechts-
      Rand des gedrehten Inhalts auf physisch RECHTS/LINKS/OBEN/UNTEN des
      (weiterhin im Hochformat gehaltenen) Geraets ab (Eckpunkt-Nachweis
      per getBoundingClientRect() gemessen, siehe Commit): #topbar (CSS-
      oben) landet physisch RECHTS, #bottom mit Papierkorb+Label-Leiste
      (CSS-unten) landet physisch LINKS. Der Papierkorb sass dadurch nur
      ~20px vom physischen UNTEREN Bildschirmrand entfernt - exakt der
      Bereich, den iOS fuer die Home-Indicator-Wischgeste (rauf = Home/
      App-Wechsler) reserviert; die Label-Leiste sass ebenso dicht am
      physisch LINKEN/OBEREN Rand, wo Safaris eigene Zurueck/Vorwaerts-
      Wischgesten fuer die Seitennavigation greifen. Diese System-/
      Browsergesten lassen sich aus keiner Website (auch keiner nativen
      App) per CSS/JS vollstaendig unterdruecken - einzige verlaessliche
      Gegenmassnahme ist, interaktive Elemente per Puffer von allen vier
      physischen Raendern fernzuhalten. Fix: einheitliches Padding auf der
      gedrehten body-Box (box-sizing:border-box, daher bleibt die exakte
      100dvh/100dvw-Rotationsgeometrie unangetastet, nur die Nutzflaeche
      innen schrumpft leicht).
*/
@media (orientation: portrait) {
  html[data-device="touch"] body {
    position: fixed;
    top: 0;
    left: 100%;
    width: 100dvh;
    height: 100dvw;
    transform-origin: 0 0;
    transform: rotate(90deg);
    overflow: hidden;
    box-sizing: border-box;
    /* Notch/Dynamic-Island/Home-Indicator (Julians Testfund 2026-09-23:
       UI-Elemente wie die SCOPE-Marke/der Papierkorb wirkten oben/unten
       abgeschnitten): env(safe-area-inset-*) lieferte bislang ueberall 0,
       weil das <meta name="viewport">-Tag kein viewport-fit=cover gesetzt
       hatte (Pflichtvoraussetzung dafuer, siehe index.html) - die feste
       18px-Pufferzone war also nirgends durch den tatsaechlichen Notch-/
       Dynamic-Island-/Home-Indicator-Bereich abgesichert. Welche der vier
       physischen Kanten (Notch vs. Home-Indicator) nach der 90°-Drehung auf
       welche CSS-Seite faellt, wurde bewusst NICHT einzeln hergeleitet -
       siehe MOBILE_PLAN.md/project_geogame_mobile_plan-Memory: Claudes
       eigene Geometrie-Herleitung zur visuellen Ausrichtung nach der
       Rotation lag in dieser Codebase schon mehrfach falsch. Stattdessen
       hier sicherheitshalber der groesste der vier realen Insets auf ALLE
       vier CSS-Seiten angewandt (etwas mehr Puffer als noetig auf den
       Seiten ohne Notch/Indicator, aber nie zu wenig auf der, die ihn hat). */
    padding: max(24px, env(safe-area-inset-top), env(safe-area-inset-right),
      env(safe-area-inset-bottom), env(safe-area-inset-left));
  }
  /* Gleiche Korrektur wie im @media(orientation:landscape)-Block oben, aus
     demselben Grund: body's Padding wirkt nur auf normal-Flow-Nachfahren,
     nicht auf diese position:fixed-Vollbild-Screens (deren inset:0 bezieht
     sich auf body's PADDING-Box, die trotz Padding bis an den aeusseren Rand
     reicht) - direkte inset-Werte auf den Screens selbst umgehen das. */
  html[data-device="touch"] #start-screen,
  html[data-device="touch"] .legal-modal,
  html[data-device="touch"] #lang-screen,
  html[data-device="touch"] #tutorial-info-screen,
  html[data-device="touch"] #results-screen,
  html[data-device="touch"] #image-preview-modal,
  html[data-device="touch"] #familiarity-gallery-screen {
    top: max(24px, env(safe-area-inset-top), env(safe-area-inset-right),
      env(safe-area-inset-bottom), env(safe-area-inset-left));
    right: max(24px, env(safe-area-inset-top), env(safe-area-inset-right),
      env(safe-area-inset-bottom), env(safe-area-inset-left));
    bottom: max(24px, env(safe-area-inset-top), env(safe-area-inset-right),
      env(safe-area-inset-bottom), env(safe-area-inset-left));
    left: max(24px, env(safe-area-inset-top), env(safe-area-inset-right),
      env(safe-area-inset-bottom), env(safe-area-inset-left));
  }
}

/* ── Touch-Drag (WP2) ─────────────────────────────────────────
   Verhindert, dass der Browser eine Ziehgeste auf den Chips/der Buehne/dem
   Papierkorb als Seiten-Scroll oder Pinch-Zoom interpretiert - ohne dieses
   touch-action:none kann iOS/Android die Geste mittendrin kapern und ein
   pointercancel statt der erwarteten pointermove-Folge ausloesen. Bewusst
   NICHT global auf body/html gesetzt, damit z.B. die Ergebnistabelle oder
   Legal-Modals weiterhin normal scrollbar bleiben.
*/
html[data-device="touch"] .label-chip,
html[data-device="touch"] #stage,
html[data-device="touch"] #trash {
  touch-action: none;
}

/* ── Kompaktere Info-/Formular-Panels auf Touch (WP3, 2026-09-02) ────────
   Julians Testfund: Tutorial-Textbloecke passten nicht auf ein Handy-
   Display (Rotationstrick macht die physische Geraetebreite zur
   verfuegbaren Hoehe - bei einem Telefon oft nur ~370-390px minus
   Randabstand). Kleinere Schrift/Abstaende verringern, wie oft ueberhaupt
   gescrollt werden muss; der margin:auto-Fix in tutorial.css sorgt
   zusaetzlich dafuer, dass der Rest bei Bedarf wirklich vollstaendig
   erreichbar bleibt. */
html[data-device="touch"] .tut-info-panel {
  padding: 12px 16px;
  gap: 5px;
  /* Ein deutlich breiteres Panel laesst Text auf weniger Zeilen umbrechen
     und reduziert dadurch direkt den Scroll-Bedarf - var(--landscape-w)
     zeigt immer auf die tatsaechlich sichtbare Querformat-Breite, egal ob
     die per Rotationstrick simuliert oder das Geraet schon physisch quer
     gehalten wird (siehe Definition weiter oben). */
  width: min(640px, calc(var(--landscape-w) * 0.86));
}
html[data-device="touch"] .tut-info-panel h2 {
  font-size: 17px;
  line-height: 1.1;
}
html[data-device="touch"] .tut-info-panel .tut-step-badge {
  font-size: 9px;
}
html[data-device="touch"] .tut-info-panel .tut-subtitle {
  font-size: 11px;
  margin-bottom: -4px;
}
html[data-device="touch"] .tut-info-panel p {
  font-size: 12.5px;
  line-height: 1.35;
}
html[data-device="touch"] .tut-info-panel .tut-note {
  font-size: 10.5px;
  line-height: 1.35;
  padding-left: 8px;
}
html[data-device="touch"] .tut-info-panel .tut-btn-row {
  margin-top: 2px;
}
/* Profilwahl (2026-10-19): kompakter, Liste scrollt innerhalb der sichtbaren
   Querformat-Hoehe; Tap-Ziele bleiben >= 44px (siehe tutorial.css .who-pick). */
html[data-device="touch"] .who-panel {
  width: min(520px, calc(var(--landscape-w) * 0.8));
}
html[data-device="touch"] .who-list {
  max-height: calc(var(--landscape-h) - 225px);
}
html[data-device="touch"] .who-pick {
  font-size: 13px;
  padding: 8px 12px;
}

/* Kategorie-Erklaerung (2026-10-19): Panel breiter, Bildbreite aus der
   verfuegbaren Querformat-Hoehe abgeleitet (~240px fuer Titel, Text, Tipp,
   Fortschritt, Buttons), mit Untergrenze; der margin:auto-Fix in
   tutorial.css haelt den Rest per Scroll erreichbar. */
html[data-device="touch"] .tut-cat-panel {
  width: min(720px, calc(var(--landscape-w) * 0.92));
}
/* Handy/Tablet im Querformat: Bilder links, Text rechts (spart Hoehe). Bei
   zwei Bildern liegen sie nebeneinander in der linken Spalte. */
html[data-device="touch"] .tut-cat-main {
  flex-direction: row;
  align-items: flex-start;
  gap: 12px;
}
html[data-device="touch"] .tut-cat-imgs {
  flex: 0 0 auto;
  gap: 8px;
  justify-content: flex-start;
}
html[data-device="touch"] .tut-cat-text {
  flex: 1 1 0;
  gap: 6px;
}
html[data-device="touch"] .tut-cat-fig {
  width: clamp(96px, calc((var(--landscape-h) - 230px) * 1.333), 150px);
}
html[data-device="touch"] .tut-cat-imgs .tut-cat-fig:only-child {
  width: clamp(120px, calc((var(--landscape-h) - 230px) * 1.333 * 1.15), 190px);
}
html[data-device="touch"] .tut-cat-fig figcaption {
  font-size: 10px;
  margin-top: 2px;
}
html[data-device="touch"] .tut-cat-tip {
  font-size: 11.5px;
  line-height: 1.35;
  padding: 5px 8px;
}
html[data-device="touch"] .tut-scalebar i {
  font-size: 9px;
  bottom: 8px;
}
html[data-device="touch"] .tut-btn {
  padding: 9px 20px;
  font-size: 13px;
}
html[data-device="touch"] .tut-btn-skip {
  padding: 9px 14px;
  font-size: 12px;
}

/* Personendaten-Formular: die neu gewonnene Panel-Breite (siehe oben) fuer
   ein zweispaltiges Layout nutzen statt eine lange Einzelspalte - halbiert
   die Zeilenzahl und damit den Scroll-Bedarf auf dem Handy. Titel/Intro/
   Fehlerhinweis/Weiter-Button bleiben ueber beide Spalten hinweg. Reihen
   selbst kompakter (kleineres Label, weniger Innenabstand bei Input/
   Select) - die 44px-Mindesthoehe der eigentlichen Tipp-/Tap-Flaeche
   (Input/Select/Custom-Select-Button) bleibt dabei unangetastet. */
html[data-device="touch"] .tut-info-panel:has(.tut-form-row) {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 2px 16px;
  align-items: start;
}
html[data-device="touch"] .tut-info-panel:has(.tut-form-row) h2,
html[data-device="touch"] .tut-info-panel:has(.tut-form-row) > p,
html[data-device="touch"] .tut-info-panel:has(.tut-form-row) .tut-form-error,
html[data-device="touch"] .tut-info-panel:has(.tut-form-row) .tut-btn-row {
  grid-column: 1 / -1;
}
html[data-device="touch"] .tut-form-row {
  gap: 2px;
}
html[data-device="touch"] .tut-form-row label {
  font-size: 0.74rem;
  line-height: 1.15;
}
html[data-device="touch"] .tut-form-row input {
  padding: 5px 8px;
  min-height: 44px;
  box-sizing: border-box;
}

/* ── Custom-Select statt natives <select> auf Touch (WP3, 2026-09-02) ───
   Julians Testfund: das native Auswahl-Popup (und ebenso die virtuelle
   Tastatur) wird vom Betriebssystem gerendert, nicht von der Seite - es
   ignoriert jedes CSS-transform der Seite und erscheint dadurch NICHT
   gedreht, waehrend der Rest der Oberflaeche erzwungen im Querformat
   steht. Das laesst sich nicht "staerker drehen" (harte Plattformgrenze,
   betrifft jede Website/App mit CSS-Rotationstrick). Fix: das native
   <select> bleibt im DOM (Formularlogik/-werte unveraendert), wird aber
   nur optisch versteckt und durch ein selbstgebautes Button+Listen-Widget
   ersetzt (siehe enhanceSelectsForTouch_() in tutorial.js) - das sind
   normale DOM-Elemente und drehen sich deshalb korrekt mit. */
html[data-device="touch"] .tut-form-row select {
  position: absolute;
  opacity: 0;
  pointer-events: none;
}
.custom-select { position: relative; }
.custom-select-btn {
  width: 100%; min-height: 44px; text-align: left;
  padding: 8px 32px 8px 10px; border: 1px solid var(--line); border-radius: 6px;
  font-family: inherit; font-size: 0.92rem; background: var(--panel-soft); color: #1a1a1a;
  position: relative;
}
.custom-select-btn::after {
  content: "▾"; position: absolute; right: 12px; top: 50%; transform: translateY(-50%);
  color: var(--muted);
}
.tut-form-row.invalid .custom-select-btn { border-color: var(--warn); }
.custom-select-list {
  position: absolute; top: calc(100% + 4px); left: 0; right: 0; z-index: 10;
  max-height: calc(var(--landscape-h) * 0.38); overflow-y: auto;
  background: var(--panel-soft); border: 1px solid var(--line); border-radius: 6px;
  box-shadow: 0 8px 24px rgba(0,0,0,.18);
}
.custom-select-opt {
  display: block; width: 100%; min-height: 44px; text-align: left;
  padding: 10px 12px; border: none; border-bottom: 1px solid var(--line);
  background: none; font-family: inherit; font-size: 0.88rem; color: #1a1a1a;
}
.custom-select-opt:last-child { border-bottom: none; }
.custom-select-opt:active { background: rgba(12,164,209,.12); }

/* ── Alias-Raeder kompakter auf Touch (WP3, 2026-09-02) ──────────────────
   Julians Testfund: die Desktop-Massgroesse (5 sichtbare Reihen a 44px =
   220px Radhoehe) allein fraß auf einem Handy im erzwungenen Querformat
   (oft nur ~370-390px Gesamthoehe) den Grossteil des Platzes und erzwang
   starkes Scrollen. 3 statt 5 sichtbare Reihen a 30px (90px statt 220px) -
   die Werte MUESSEN exakt zu ALIAS_ITEM_HEIGHT in tutorial.js passen,
   sonst desynchronisiert die Scroll-Snap-Positionsberechnung von der
   Optik (siehe Kommentar dort). */
html[data-device="touch"] .alias-wheel {
  height: 90px;
}
html[data-device="touch"] .alias-wheel-pad {
  height: 30px;
}
html[data-device="touch"] .alias-wheel-item {
  height: 30px;
  font-size: 11px;
}
html[data-device="touch"] .alias-wheel-item.dist-1 {
  font-size: 12px;
}
html[data-device="touch"] .alias-wheel-item.dist-0 {
  font-size: 13px;
}
html[data-device="touch"] .alias-wheel-highlight {
  height: 30px;
}
html[data-device="touch"] .alias-wheel-col::before,
html[data-device="touch"] .alias-wheel-col::after {
  height: 24px;
}
html[data-device="touch"] .alias-preview {
  padding: 6px 10px;
  font-size: 15px;
}
html[data-device="touch"] .alias-picker p {
  margin-bottom: 0;
}

/* Overlay-Tutorial-Tooltip: gleiche vw/vh-Problematik wie ueberall sonst
   auf dieser Seite - siehe --landscape-w/-h-Definition oben. */
html[data-device="touch"] #tut-tooltip {
  width: min(420px, calc(var(--landscape-w) * 0.8));
  padding: 12px 16px;
}
html[data-device="touch"] #tut-tooltip h3 {
  font-size: 13px;
  margin-bottom: 4px;
}
html[data-device="touch"] #tut-tooltip p {
  font-size: 12px;
  line-height: 1.4;
  margin: 0 0 8px;
}

/* ── Vollbild-Hinweis-Popup kompakter auf Touch (2026-09-23, verschaerft
   nach Julians zweitem Testfund auf echtem iPhone - die erste Kompaktierung
   reichte auf seinem Geraet noch nicht, er musste weiterhin scrollen) ──────
   var(--landscape-w)/(-h) statt fixer px-Werte, damit es auf die tatsaechlich
   sichtbare Flaeche passt statt auf eine angenommene Desktop-Groesse (gleiches
   Muster wie .tut-info-panel oben). Zusaetzlicher Hebel diesmal: die beiden
   Anleitungsbilder stehen auf Touch NEBENEINANDER statt untereinander (siehe
   .fs-hint-steps unten) - im erzwungenen Querformat ist die Breite reichlich
   vorhanden, die Hoehe knapp (dieselbe Ressourcen-Abwaegung wie beim Handy-
   Spiellayout weiter unten in dieser Datei), eine Bildreihe statt zwei
   spart die Haelfte der vertikal benoetigten Bildhoehe. */
html[data-device="touch"] #fullscreen-hint-modal .legal-modal-card {
  width: min(560px, calc(var(--landscape-w) * 0.92));
  padding: 10px 16px;
}
html[data-device="touch"] #fullscreen-hint-modal h1 {
  font-size: 0.95rem;
  margin-bottom: 5px;
}
html[data-device="touch"] #fullscreen-hint-modal p {
  font-size: 0.74rem;
  line-height: 1.3;
  margin-bottom: 5px;
}
html[data-device="touch"] #fullscreen-hint-modal .fs-hint-steps {
  display: flex;
  gap: 10px;
  align-items: flex-start;
}
html[data-device="touch"] #fullscreen-hint-modal .fs-hint-step {
  flex: 1;
  min-width: 0;
  margin-bottom: 0;
}
html[data-device="touch"] #fullscreen-hint-modal .fs-hint-step img {
  width: auto;
  max-width: 100%;
  max-height: calc(var(--landscape-h) * 0.32);
  margin: 0 auto 4px;
}
html[data-device="touch"] #fullscreen-hint-modal .fs-hint-step p {
  font-size: 0.68rem;
  line-height: 1.2;
  margin-bottom: 0;
}
html[data-device="touch"] #fullscreen-hint-modal .fs-hint-actions {
  margin-top: 5px;
  gap: 6px;
}
html[data-device="touch"] #fullscreen-hint-modal .fs-hint-actions button {
  padding: 6px 12px;
  font-size: 0.76rem;
}
html[data-device="touch"] #fullscreen-hint-modal .fs-hint-note {
  font-size: 0.66rem;
  line-height: 1.25;
  margin-top: 4px;
}
html[data-device="touch"] #fullscreen-hint-modal .legal-modal-card button.fs-hint-skip {
  margin-top: 5px;
  font-size: 0.7rem;
  padding: 2px;
}

/* ── Debug-Panel kleiner auf dem Handy (2026-09-23) ───────────────────────
   Julians eigentlicher Kernpunkt (praezisiert nach Nachfrage): nicht in
   erster Linie Lupe/Konturen, sondern die Debug-Panel-Karte selbst (Check-
   boxen, Alle-an/aus, Level-Navigation, Aufgaben-Steuerung) - die war fuers
   Desktop bemessen und nahm auf dem kleinen Bildschirm unverhaeltnismaessig
   viel vom Satellitenbild ein. */
html[data-tier="phone"] #debug-panel {
  min-width: 130px;
  padding: 7px 9px;
  font-size: 9px;
  top: 6px;
  right: 6px;
}
html[data-tier="phone"] #debug-panel-title {
  font-size: 8px;
  margin-bottom: 5px;
  gap: 3px;
}
html[data-tier="phone"] #debug-panel-hint {
  font-size: 7px;
}
html[data-tier="phone"] #debug-panel-collapse-btn {
  font-size: 9px;
}
html[data-tier="phone"] #debug-checks {
  gap: 4px;
  margin-top: 1px;
}
html[data-tier="phone"] .debug-check-row {
  gap: 5px;
}
html[data-tier="phone"] .debug-check-row input[type=checkbox] {
  width: 11px;
  height: 11px;
}
html[data-tier="phone"] .debug-swatch {
  width: 9px;
  height: 9px;
}
html[data-tier="phone"] .debug-check-label {
  font-size: 9px;
}
html[data-tier="phone"] #debug-btns {
  margin-top: 6px;
  padding-top: 6px;
  gap: 5px;
}
html[data-tier="phone"] .debug-btn {
  padding: 3px 0;
  font-size: 8px;
}
html[data-tier="phone"] .debug-section {
  margin-top: 5px;
  padding-top: 6px;
}
html[data-tier="phone"] .debug-section-title {
  font-size: 7px;
  margin-bottom: 4px;
}
html[data-tier="phone"] .debug-nav-row {
  gap: 4px;
}
html[data-tier="phone"] .debug-nav-btn {
  flex-basis: 24px;
}
html[data-tier="phone"] .debug-level-info {
  font-size: 8px;
}
html[data-tier="phone"] .debug-task-col {
  gap: 4px;
}
/* Hint-Layers-Panel (schlanke Variante ohne QA-Steuerung, siehe "Ich komme
   nicht weiter") teilt denselben Desktop-bemessenen Look. */
html[data-tier="phone"] #hint-layers-panel {
  padding: 7px 9px;
  font-size: 9px;
  top: 6px;
  right: 6px;
}
html[data-tier="phone"] #hint-layers-title {
  font-size: 8px;
  margin-bottom: 5px;
}
html[data-tier="phone"] #hint-layers-checks {
  gap: 4px;
}

/* ── Lupe/Debug-Reticle kleiner auf dem Handy (2026-09-23) ───────────────
   Julians Testfund: die Lupe (fix 250px Durchmesser, fuers Desktop bemessen)
   nahm auf einem kleinen Handybildschirm einen unverhaeltnismaessig grossen
   Teil des Satellitenbilds ein. Reiner CSS-transform:scale() statt die JS-
   Konstante LOUPE_D zu aendern - das haette auch die Drag-Positionierungs-
   Mathematik (Puffer-Abstand zum Finger, Clamping an die Buehnenraender in
   app.js) mit verschieben muessen. scale() schrumpft nur die Optik um den
   bereits korrekt berechneten Mittelpunkt, ohne dass sich an der Positions-
   logik etwas aendert - muss mit dem bestehenden translate(-50%,-50%) der
   Basisregel kombiniert werden (die zweite transform-Deklaration ersetzt die
   erste komplett, nicht additiv). */
html[data-tier="phone"] #loupe {
  transform: translate(-50%, -50%) scale(0.62);
}
/* Handy-Drag: Lupe haengt an <body> (siehe app.js setLoupeHost_) und liegt
   links neben dem Finger in Viewport-Koordinaten. */
#loupe.loupe-fixed {
  position: fixed;
}

/* ── Kompaktes Bestaetigungs-Badge auf dem Handy (2026-09-23) ────────────
   Ersetzt den vollen ".zone-ok"-Textblock (Icon+Klassenname) durch ein
   kleines rundes Haekchen-Badge, siehe app.js: handleStageDrop() setzt die
   Klasse nur auf Phone-Tier. Grund: der Textblock verdeckte auf dem kleinen
   Bildschirm spuerbar viel vom eigentlichen Satellitenbild. */
.zone-ok-compact {
  padding: 0;
  width: 20px;
  height: 20px;
  display: flex;
  align-items: center;
  justify-content: center;
  border-radius: 50%;
  font-size: 12px;
  line-height: 1;
}

/* ── Spiel-Layout auf dem Handy: Bild links, Bedienung rechts (WP3,
   2026-09-02) ────────────────────────────────────────────────────────
   Julians Idee: im erzwungenen Querformat ist die Hoehe knapp, die Breite
   reichlich - #label-bar/#trash bisher in #bottom UNTER dem Bild kosteten
   wertvolle Hoehe, waehrend #sidebar-left/#sidebar-right (bisher rein
   dekorative Letterbox-Flaechen neben dem exakt-4:3-Bild) ungenutzt
   blieben. Bewusst NUR fuers Handy (data-tier="phone"), nicht Tablet -
   Julian ist mit der Tablet-Version bereits zufrieden, dort ist genug
   Hoehe vorhanden. Die eigentliche Umhaengung von #label-bar/#trash nach
   #sidebar-right passiert in JS (relocatePhoneControls_() in app.js) -
   CSS kann Elemente nicht zwischen verschiedenen Flex-Eltern umsortieren. */
html[data-tier="phone"] #bottom {
  display: none;
}
html[data-tier="phone"] #sidebar-left {
  flex: 0 0 0;
  min-width: 0;
}
html[data-tier="phone"] #sidebar-right {
  flex: 1 1 auto;
  min-width: 150px;
  display: flex;
  flex-direction: column;
  align-items: stretch;
  justify-content: flex-start;
  gap: 3px;
  padding: 5px;
  background: linear-gradient(180deg,var(--panel-dark) 0%,var(--panel) 100%);
  color: initial;
  font-size: initial;
  letter-spacing: normal;
  overflow-y: auto;
}
/* Topbar (Marke/Fortschritt/Zeit+Fehler) wird von app.js:
   relocatePhoneControls_() ebenfalls in #sidebar-right umgehaengt (Julians
   ausdruecklicher Wunsch: nicht nur die untere Leiste, auch die obere soll
   nach rechts ruecken, damit das Bild links die VOLLE Bildschirmhoehe
   bekommt statt dass die Topbar oben quer drueberlaeuft). Die Desktop-
   Topbar ist eine breite Reihe (fixe 380px-Fortschrittsbreite) - in der
   schmalen Spalte stattdessen alles untereinander. */
html[data-tier="phone"] #sidebar-right #topbar {
  display: flex;
  flex-direction: column;
  align-items: stretch;
  gap: 2px;
  padding: 0 0 5px;
  margin-bottom: 2px;
  border-bottom: 1px solid var(--accent);
  background: none;
  width: 100%;
  box-sizing: border-box;
  flex-shrink: 0;
}
html[data-tier="phone"] #sidebar-right #progress-wrap {
  width: 100%;
}
/* SCOPE-Marke sitzt jetzt (siehe relocatePhoneControls_() in app.js) als
   erstes Kind in dieser Zeile statt in einer eigenen Zeile darueber - spart
   eine ganze Zeile Hoehe. Reihenfolge: SCOPE | LEVEL 1/8 | ... | 0% (Prozent
   per margin-left:auto ganz nach rechts gedrueckt, "LEVEL 1/8" ruecken direkt
   neben die Marke statt ueber den ganzen Rest verteilt zu werden). */
html[data-tier="phone"] #sidebar-right #progress-label {
  display: flex;
  align-items: baseline;
  gap: 7px;
  margin-bottom: 2px;
}
html[data-tier="phone"] #sidebar-right #progress-label #prog-pct {
  margin-left: auto;
}
html[data-tier="phone"] #sidebar-right #topbar .brand {
  flex-shrink: 0;
}
/* Julians Testfund (2026-09-23): trotz der bereits kompakteren Phone-Tier-
   Werte wirkte die Seitenleiste im Spiel noch sehr luftig (viel ungenutzter
   Platz zwischen Zeit/Fehler-Block und den Labels) und musste gescrollt
   werden. Groesster Hebel: die 4 Label-Buttons standen einzeln untereinander
   (4 Zeilen) - als 2x2-Raster (siehe #label-bar unten) halbiert sich ihr
   Platzbedarf, dieselbe "Breite reichlich, Hoehe knapp"-Abwaegung wie schon
   beim Vollbild-Popup und den iOS-Anleitungsbildern. Zusaetzlich Abstaende/
   Schrift ueberall in dieser Spalte weiter verkleinert. */
html[data-tier="phone"] #sidebar-right #stats {
  gap: 10px;
  justify-content: center;
}
html[data-tier="phone"] #sidebar-right .stat-val {
  font-size: 13px;
}
html[data-tier="phone"] #sidebar-right .stat-label {
  font-size: 7px;
  margin-top: 0;
}

html[data-tier="phone"] #sidebar-right #label-bar {
  display: grid;
  /* minmax(0,1fr) statt 1fr: Grid-Spalten haben sonst ein implizites
     min-width:auto und schrumpfen nie unter die Breite des laengsten
     unzerbrechlichen Wort-Tokens - "Grünland/Landwirtschaft" (kein
     natuerlicher Umbruchpunkt am "/") sprengte dadurch real gemessen die
     Spaltenbreite um ~10px ueber den Seitenleisten-Rand hinaus. */
  grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
  /* Julians Testfund (2026-09-23): unter den Buttons blieb sichtbar Luft vor
     dem Papierkorb, weil #trash die per margin-top:auto uebrige Hoehe fuer
     sich beanspruchte, statt dass die Buttons selbst sie nutzen. flex:1 auf
     das Grid + 1fr-Zeilen (statt automatisch inhaltsbreiter Zeilen) lassen
     die Button-Reihen stattdessen wachsen - die Buttons werden dadurch
     spuerbar groesser/leichter zu treffen. */
  grid-template-rows: auto 1fr 1fr;
  flex: 1 1 auto;
  min-height: 0;
  gap: 5px;
  /* Desktop-Basisregel (style.css) setzt align-items:center fuers dortige
     Flex-Layout - das "leckt" hier durch und verhindert, dass kuerzere
     Chips (Wald/Wasser) ihre Rasterzeile wie gewuenscht ausfuellen (sie
     wurden stattdessen nur mittig in der volleren Zeilenhoehe der
     laengeren Nachbarn platziert). stretch macht alle 4 wirklich gleich
     hoch, nicht nur zeilenweise gleich. */
  align-items: stretch;
}
html[data-tier="phone"] #sidebar-right #label-bar-title {
  grid-column: 1 / -1;
  margin-right: 0;
  font-size: 9px;
}
html[data-tier="phone"] #sidebar-right .label-chip {
  width: 100%;
  min-width: 0;
  /* Einheitliche Hoehe (Julians Wunsch, 2026-09-23): ohne das behielt jeder
     Button nur seine eigene Inhaltshoehe (1 vs. 2 Zeilen je nach Textlaenge),
     was uneinheitlich aussah. min-height statt fester height, damit ein
     unerwartet langer Text nie abgeschnitten wird - der ermittelte
     Schlechtestfall ("Grünland/Landwirtschaft", 2 Zeilen bei 10.5px) passt
     bei 40px mit etwas Reserve. */
  min-height: 40px;
  display: flex;
  align-items: center;
  justify-content: center;
  box-sizing: border-box;
  text-align: center;
  padding: 4px 6px;
  font-size: 10.5px;
  line-height: 1.2;
  overflow-wrap: break-word;
  word-break: break-word;
}
/* Papierkorb so hoch wie eine Chip-Reihe (Julian, 2026-10-19): #label-bar
   (Titel 12px + 2 Reihen, 2 Abstaende je 5px = Basis 22px, Gewicht 2) und
   #trash (Gewicht 1) teilen sich die Resthoehe, dadurch ist jede der drei
   Reihen (2 Chip-Reihen + Papierkorb) gleich hoch. Basis 38px = 22px + 16px
   Ausgleich fuer die Mindest-Basisgroesse des Papierkorbs (Rahmen 2x2px +
   Innenabstand 2x2px = 8px, mal Gewicht 2). */
html[data-tier="phone"] #sidebar-right #label-bar {
  flex: 2 1 38px;
}
html[data-tier="phone"] #sidebar-right #label-bar-title {
  height: 12px;
  line-height: 12px;
}
html[data-tier="phone"] #sidebar-right #trash {
  margin-top: 0;
  flex: 1 1 0;
  width: 100%;
  box-sizing: border-box;
  min-height: 40px;
  gap: 1px;
  padding: 2px;
}
html[data-tier="phone"] #sidebar-right #trash #trash-count {
  min-height: 0;
}
html[data-tier="phone"] #sidebar-right #trash > div:first-child {
  font-size: 15px;
}
/* "Ich komme nicht weiter" ist auf Desktop position:fixed (bottom-left der
   Buehne) - in der Spalte stattdessen normaler Fluss, damit es sich mit
   einreiht statt ueber dem jetzt hier befindlichen Papierkorb zu schweben. */
html[data-tier="phone"] #sidebar-right #btn-hint {
  position: static;
  width: 100%;
  box-sizing: border-box;
  text-align: center;
  padding: 6px 14px;
  font-size: 12px;
}

/* ── Ablage bestaetigen/verwerfen, nur Handy (2026-10-01) ─────────────────
   Ersetzt waehrend der Rueckfrage die Chips im Label-Raster (siehe app.js
   showDropConfirm_). Grosse Tap-Ziele, da unter Zeitdruck bedient. */
html[data-tier="phone"] #sidebar-right #label-bar {
  position: relative;
}
.drop-confirm {
  position: absolute;
  inset: 0;
  z-index: 50;
  display: flex;
  flex-direction: column;
  gap: 8px;
  padding: 8px;
  box-sizing: border-box;
  /* Gleicher Kartenstil wie die Tutorial-Panels: gedaempftes Grau, hellblauer
     Rahmen, goldener Streifen oben. */
  background: var(--panel-soft, #f4f6f8);
  border: 1px solid var(--border);
  border-top: 3px solid var(--accent2);
  border-radius: 4px;
}
.drop-confirm-title {
  color: #0a3f70;
  font-family: var(--font-ui);
  font-size: 11px;
  font-weight: 700;
  letter-spacing: .03em;
  text-align: center;
}
.drop-confirm-btns {
  flex: 1;
  display: flex;
  gap: 8px;
}
.drop-confirm-btn {
  flex: 1;
  min-height: 56px;
  border-radius: 4px;
  font-family: var(--font-ui);
  font-size: 14px;
  font-weight: 700;
  color: #0a3f70;
  cursor: pointer;
}
/* Hauptaktion: goldener Verlaufsbutton wie "Weiter"/.tut-btn */
.drop-confirm-ok {
  border: none;
  border-bottom: 3px solid #8a6500;
  background: linear-gradient(180deg, #ffe566 0%, #fdc300 55%, #c99400 100%);
  box-shadow: 0 4px 14px rgba(253,195,0,.35), inset 0 1px 0 rgba(255,255,255,.5);
}
/* Nebenaktion: weisser Chip-Button wie die Label-Chips */
.drop-confirm-no {
  border: 1px solid var(--accent);
  border-bottom: 3px solid #0a3f70;
  background: linear-gradient(180deg, #ffffff 0%, #eef1f4 100%);
}
.drop-confirm-btn:active { transform: translateY(1px); }

/* Ebenen auf dem Handy (2026-10-01): die Lupe haengt waehrend des Drags an
   <body> (z-index 600, siehe oben) und lag dadurch ueber Topbar und
   Seitenleiste (z-index 100 bzw. auto), waehrend sie auf Desktop/Tablet in
   #stage steckt und nie ueber ein Menue ragen kann. Menue jetzt ueber der
   Lupe - app.js haelt sie ausserdem per Position aus dem Menue heraus. */
html[data-tier="phone"] #topbar,
html[data-tier="phone"] #sidebar-right {
  z-index: 650;
}

/* Laptop/Tablet: "Weiter"-Karte liegt ueber "Nicht vorhanden" + "Ich komme
   nicht weiter" (Position/Groesse setzt app.js showNextPopup_ inline). */
.drop-confirm.drop-confirm-lower {
  inset: auto;
  /* #btn-hint hat z-index:800 (war frueher ein schwebender Button) - die Karte
     muss darueber liegen, da sie ihn mit abdeckt. */
  z-index: 900;
}
