/* Banasport-Light-Theme für den Fancy Product Designer.
 * Basis hell (passt zum restlichen Banasport-Frontend), Banasport-Grün als
 * Akzent, Neon-Grün für Hover/Active. */

:root {
  /* Akzent + Buttons */
  --fpd-secondary-color: #3f8a2f;
  --fpd-secondary-fg-color: #ffffff;
  --fpd-btn-primary-color: #3f8a2f;
  --fpd-btn-primary-text-color: #ffffff;

  /* Text + Borders — dunkle Schrift auf hellem Grund */
  --fpd-primary-color: #1e1e1e;
  --fpd-primary-fg-color: #ffffff;
  --fpd-text-color: #1e1e1e;
  --fpd-input-text-color: rgba(0, 0, 0, 0.8);
  --fpd-mainbar-nav-color: #1e1e1e;
  --fpd-border-color: #e5e7eb;
  --fpd-light-grey-color: #e5e7eb;
  --fpd-dark-grey-color: #6b7280;

  /* Flächen */
  --fpd-light-bg-color: #ffffff;
  --fpd-actions-bar-bg-color: #f4f6f4;
  --fpd-actions-bar-height: 54px;
  --fpd-list-bg-color-active: rgba(63, 138, 47, 0.10);

  /* Shape */
  --fpd-border-radius: 12px;
}

/* Outer container frame — hellgrau statt weiß. */
.fpd-banasport {
  border-radius: 16px;
  overflow: hidden;
  border: 1px solid #e5e7eb;
  background: #f4f6f4;
}

/* WICHTIG: FPD definiert seine Farb-Variablen selbst in :root und lädt sein
   CSS NACH unserem fpd-brand.css → bei gleicher Spezifität (beide :root) gewinnt
   FPDs Blau (#029EEB). Unsere :root-Overrides oben sind dadurch für alles, was
   FPD per Variable stylt, wirkungslos (z.B. die Action-Buttons „Text hinzufügen",
   „Datei wählen" blieben blau). Lösung: dieselben Variablen auf .fpd-container
   setzen — der nähere Vorfahre gewinnt bei der Variablen-Vererbung, egal welche
   CSS-Datei später lädt. So sind ALLE FPD-Buttons/Akzente konsistent Banasport-grün. */
.fpd-container,
fpd-element-toolbar,
fpd-modal-wrapper {
  --fpd-secondary-color: #3f8a2f;
  --fpd-btn-primary-color: #3f8a2f;
}

/* Layout-Override für mainBarContainer="#fpd-host":
   FPD hängt fpd-main-bar und fpd-main-wrapper als GESCHWISTER unter den
   Container — default-flex-column stapelt die untereinander. Wir
   erzwingen ein 2-Spalten-Grid, damit Sidebar und Stage nebeneinander
   liegen wie im Kokott-Original. */
#fpd-host.fpd-banasport.fpd-sidebar {
  --fpd-sidebar-width: 450px;   /* bleibt 450px: Modul-Panel-Breite, unverändert seit Paket 9 — die Element-Toolbar füllt diese Spalte seit Paket 8/9 ohnehin immer voll aus (Tool-Grid ODER Sub-Panel, nie beide nebeneinander, s.u.), die Sidebar-Gesamtbreite selbst ist davon unberührt */
  display: grid !important;
  grid-template-columns: var(--fpd-sidebar-width) 1fr;
  grid-template-rows: auto 1fr;
  grid-template-areas:
    "topbar topbar"
    "sidebar stage";
  /* Höhe an den sichtbaren Viewport koppeln, sonst läuft der Designer auf
     Notebook-Bildschirmen (z.B. 1366x768) unten aus dem Bild (Dennis 2026-06-20).
     Über dem Designer liegen Website-Header (~72px) + Hero-Überschrift (~120px).
     !important nötig: FPD setzt selbst „min-height:720px" INLINE auf #fpd-host. */
  min-height: 0 !important;
  height: clamp(440px, calc(100dvh - 205px), 800px) !important;
}
#fpd-host.fpd-banasport.fpd-sidebar > fpd-actions-bar { grid-area: topbar; }
#fpd-host.fpd-banasport.fpd-sidebar > fpd-main-bar    { grid-area: sidebar; height: 100% !important; }
#fpd-host.fpd-banasport.fpd-sidebar > fpd-main-wrapper { grid-area: stage; min-height: 0; }

/* ─── Höhen-bewusste Stage-Skalierung (Dennis 2026-07-02) ────────────────────
   Problem: FPDs Responsive-Resize skaliert die Trikots NUR über die BREITE des
   Canvas-Containers (gemessen wird per JS die clientWidth von .fpd-product-stage,
   Skala = Breite / stageWidth 1000; Canvas-Höhe folgt mit ×720/1000). Bei breiten,
   aber FLACHEN Fenstern (z.B. 1280×560, große Monitore mit niedrigem Fenster)
   wurde der Canvas dadurch HÖHER als die Stage-Zelle → Trikots ragten unter den
   sichtbaren Bereich, Scrollen nötig, Elemente kaum bearbeitbar.
   Lösung rein in CSS: die BREITE von .fpd-product-stage an die verfügbare HÖHE
   koppeln. Verfügbare Stage-Höhe = Host-Höhe (identische clamp-Formel wie oben
   auf #fpd-host!) minus Actions-Bar (54px) minus 12px Luft; mal Seitenverhältnis
   1000/720 ergibt die maximal erlaubte Canvas-Breite. Wird das Fenster flacher,
   schrumpft die max-width → FPD liest beim window-resize die kleinere clientWidth
   und skaliert die Trikots von selbst herunter (kein JS nötig; ein reines
   height/overflow-Kappen würde dagegen nur abschneiden statt skalieren).
   Bei normalen Höhen (z.B. 1280×800: Cap ≈ 735px > natürliche ~730px Spaltenbreite;
   ab ~Host-Max 800px liegt der Cap über stageWidth 1000) greift die Regel NICHT —
   dort bleibt alles exakt wie bisher. Zentrierung: FPDs eigenes margin:auto im
   Flex-Wrapper zieht die schmalere Stage automatisch mittig; margin-inline:auto
   hier nur zur Absicherung. Nur Desktop-Grid (≥1024px) — Mobil (s.u.) regelt die
   Höhe bereits über aspect-ratio/max-height. */
@media (min-width: 1024px) {
  #fpd-host.fpd-banasport.fpd-sidebar > fpd-main-wrapper .fpd-product-stage {
    max-width: calc((clamp(440px, 100dvh - 205px, 800px) - var(--fpd-actions-bar-height, 54px) - 12px) * 1000 / 720);
    margin-inline: auto; /* bei begrenzter Breite mittig, nicht linkslastig */
  }
}

/* Module-Panel: gleicher Grauton wie der Rest, kein weißer Block */
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-module-content {
  background: #f4f6f4 !important;
}
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-module-content > .fpd-active {
  background: transparent !important;
}

/* Sidebar-Nav (linke Icon-Spalte): zurück auf EINE Spalte (QA 2026-07-02) →
   110px reichen für Icon + Label („Produkte") untereinander; das Modul-Panel
   bekommt den Rest der --fpd-sidebar-width (~340px). */
#fpd-host.fpd-banasport.fpd-sidebar {
  --fpd-sidebar-nav-width: 110px;
}

/* ─── Kleiner Bildschirm: Sidebar-Panels scrollen INNERHALB des Designers ───
   Dennis 2026-06-29: bei ~1366×620 wurde alles unter dem Designer-Rand
   abgeschnitten — letztes Trikot, Diskette (Designs-Tab), gespeicherte Designs
   nicht erreichbar. Ursache: fpd-main-bar hatte min-height:500 + Grid-default
   min-height:auto (Blowout) → wuchs auf 540px über die 440px-Grid-Zelle hinaus,
   #fpd-host (overflow:hidden) kappte den Rest. Fix: durchgehende Höhenkette von
   der Grid-Zelle bis zur FPD-Scroll-Area, sodass der Modul-Inhalt im Designer
   scrollt statt abgeschnitten zu werden. */
#fpd-host.fpd-banasport.fpd-sidebar > fpd-main-bar {
  min-height: 0 !important;       /* statt 500px → respektiert die Grid-Zelle */
  overflow: hidden !important;    /* nichts ragt über die Zelle hinaus */
  /* Paket 3 (Dennis 2026-07-02): FPD capt die main-bar hart auf 400px
     (Regel `.fpd-container.fpd-main-bar-container fpd-main-bar{width:400px}`) —
     in der 450px-Grid-Zelle lagen dadurch 50px BRACH. width:100% füllt die Zelle,
     der Gewinn geht komplett ans Sub-Panel (Farbe/Schatten: 188→238px breit);
     die Stage-Spalte (1fr) bleibt unverändert. */
  width: 100% !important;
  /* FPD gibt fpd-main-bar margin-top:20px → die Sidebar startet 20px tiefer als die
     Canvas-Spalte und ragt unten über den Host-Rand (5. Nav-Icon „Designs"/Diskette
     wurde abgeschnitten). Im Grid-Layout fluchtet die Sidebar oben mit der Canvas. */
  margin-top: 0 !important;
}
/* Icon-Spalte: volle Zellhöhe, scrollt wenn nötig (sehr niedrige Fenster) */
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-navigation {
  height: 100% !important;
  min-height: 0 !important;
  overflow-y: auto !important;
  /* QA 2026-07-02: zurück auf EINE Spalte (untereinander, wie ursprünglich) —
     die 2-Spalten-Variante aus Sitzung 2 war unerwünscht. Die 5 Module
     (Produkte/Farben/Bilder/Text/Designs) passen 1-spaltig bei 1280×800 komplett
     in die Sidebar (~5×60px in ~540px Zellhöhe); bei sehr niedrigen Fenstern
     (z.B. 1280×560) greift das overflow-y:auto oben. */
  display: grid !important;
  grid-template-columns: 1fr !important;
  align-content: start !important;
  gap: 4px !important;
  padding: 8px 6px !important;
  box-sizing: border-box !important;
}
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-navigation .fpd-nav-item {
  margin: 0 !important;
  min-width: 0 !important;
}
/* Labels nicht trennen (kein „Pro-\ndukte") und nicht umbrechen */
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-navigation .fpd-label {
  hyphens: none !important;
  overflow-wrap: normal !important;
  white-space: nowrap !important;
  /* QA 2026-07-02: Label klebte weiterhin mit ~4px am Icon → 8px echte Luft.
     !important, damit weder FPDs eigene Label-Margins noch der (bei kleiner
     Höhe auf 4px reduzierte) Flex-gap den Abstand wieder wegdrücken. */
  margin-top: 8px !important;
}
/* Modul-Panel-Kette auf Zellhöhe begrenzen, damit die innere Scroll-Area greift */
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-module-content,
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-module-content > .fpd-active,
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-module-content > .fpd-active > div {
  height: 100% !important;
  min-height: 0 !important;
  overflow: hidden !important;
}
/* FPDs eigene Scroll-Area (Produkt-Grid, Bilder, gespeicherte Designs …) füllt die
   Zellhöhe und scrollt INNEN → alle Einträge erreichbar, nichts hinter dem Rand.
   WICHTIG: NUR die Modul-Panels (> .fpd-module-content), NICHT die Element-Toolbar.
   Dort trägt `.fpd-secondary-tools` ebenfalls `.fpd-scroll-area`; ein overflow-y:auto
   setzt deren implizite min-height auf 0 → sie kollabierte im Flex-Column auf Höhe 0,
   wodurch die unteren Tools (u.a. Bogen) unerreichbar wurden (Dennis QA Mangel 1). */
#fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-module-content .fpd-scroll-area {
  max-height: 100% !important;
  overflow-y: auto !important;
}
/* Bei begrenzter Höhe die 5 Modul-Icons (Produkte/Farben/Bilder/Text/Designs)
   kompakter, damit ALLE in die Sidebar passen — sonst war das 5. Icon (Designs/
   Diskette) unten raus. Volle Höhe = roomy bleibt erhalten. */
@media (max-height: 820px) {
  #fpd-host.fpd-banasport.fpd-sidebar .fpd-nav-item {
    padding: 5px 4px !important;
    margin: 0 !important;   /* Sitzung 2: Grid-Zellen selbst tragen den Abstand (gap) */
    gap: 4px !important;
  }
  #fpd-host.fpd-banasport.fpd-sidebar .fpd-nav-item .fpd-nav-icon {
    font-size: 24px !important;
    height: 26px !important;
    line-height: 26px !important;
  }
  #fpd-host.fpd-banasport.fpd-sidebar .fpd-nav-item .fpd-label {
    font-size: 11px !important;
    line-height: 1.1 !important;
  }
}

/* Canvas stage — dezent grau, damit weiße Trikots kontrastiert sichtbar sind */
.fpd-container .fpd-product-stage {
  background-color: #f4f6f4 !important;
}

/* Weißen Overlay-Layer hinter den Views entfernen — das Grau von .fpd-product-stage soll durchscheinen.
   !important, weil FPD-CSS über <link> in der Komponente nach unserem fpd-brand.css geladen wird und
   sonst in der Kaskade gewinnt. */
.fpd-wrapper > fpd-main-wrapper .fpd-product-stage > .fpd-view-stage,
.fpd-container .fpd-view-stage {
  background: transparent !important;
}

/* MainBar (Sidebar) — weiß mit dezentem Border */
.fpd-container .fpd-main-bar,
.fpd-container fpd-main-bar {
  background-color: #ffffff;
  color: #1e1e1e;
  border-right: 1px solid #e5e7eb;
}

/* Nav-Items: Icon-Label-Abstand + klare Trennung */
.fpd-container .fpd-nav-item {
  gap: 12px;
  padding: 12px 16px;
  margin: 4px 8px;
  border-radius: 10px;
  color: #1e1e1e;
  text-decoration: none !important;
  transition: all 0.15s ease;
}
.fpd-container .fpd-nav-item .fpd-label {
  font-size: 13px;
  font-weight: 500;
  color: #1e1e1e;
}
.fpd-container .fpd-nav-item:hover {
  background-color: rgba(63, 138, 47, 0.08);
}
.fpd-container .fpd-nav-item.fpd-active {
  background-color: rgba(63, 138, 47, 0.12);
}
.fpd-container .fpd-nav-item.fpd-active .fpd-label {
  color: #3f8a2f;
  font-weight: 600;
}
.fpd-container .fpd-nav-item.fpd-active .fpd-nav-icon:before,
.fpd-container .fpd-nav-item.fpd-active svg *,
.fpd-container .fpd-nav-item:hover .fpd-nav-icon:before,
.fpd-container .fpd-nav-item:hover svg * {
  color: #3f8a2f !important;
  fill: #3f8a2f !important;
}

/* Modul-Inhaltsbereich */
.fpd-container .fpd-module-content,
.fpd-container fpd-main-bar .fpd-module {
  background-color: #ffffff;
  color: #1e1e1e;
}

/* Topbar / Actions — dunkler Balken, Label + Icons weiß.
   !important, weil FPD-CSS nach unserem lädt und sonst in der Kaskade gewinnt.
   Dropdown-Menü explizit AUSGENOMMEN (das bleibt weißer Panel mit dunklem Text). */
.fpd-container fpd-actions-bar,
.fpd-container .fpd-actions-bar {
  color: #ffffff !important;
  border-bottom: 1px solid rgba(255,255,255,0.08);
}
.fpd-container fpd-actions-bar > div > fpd-actions-menu > .fpd-uncollapsed-menu .fpd-btn,
.fpd-container fpd-actions-bar > div > fpd-actions-menu > .fpd-uncollapsed-menu .fpd-label,
.fpd-container fpd-actions-bar > div > .fpd-btn,
.fpd-container fpd-actions-bar > div > .fpd-btn .fpd-label {
  color: #ffffff !important;
}

/* Dropdown-Menü (aus dem "Menü"-Button ausgeklappt) — dunkle Schrift
   trotz weißer actions-bar-Regel oben. Höhere Spezifität + !important. */
.fpd-container fpd-actions-bar fpd-actions-menu .fpd-dropdown-menu .fpd-btn,
.fpd-container fpd-actions-bar fpd-actions-menu .fpd-dropdown-menu .fpd-btn .fpd-label,
.fpd-container fpd-actions-menu .fpd-dropdown-menu .fpd-btn,
.fpd-container fpd-actions-menu .fpd-dropdown-menu .fpd-label {
  color: #1e1e1e !important;
}

/* Main-Wrapper + Main-Bar (Sidebar-Bereich) — alles was zwischen der
   Actions-Bar und dem Trikot-Stage liegt, soll einheitlich hellgrau sein.
   fpd-main-bar hat FPD-default weißen BG und zieht sich in Layouts ohne
   offenes Modul über die ganze Breite → macht den "weißen Streifen". */
.fpd-container fpd-main-wrapper,
.fpd-wrapper > fpd-main-wrapper,
.fpd-container fpd-main-bar,
.fpd-container .fpd-main-bar {
  background: #f4f6f4 !important;
}

/* File-Menu Flyout (oben links) */
.fpd-container fpd-actions-menu .fpd-dropdown-menu {
  background-color: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 12px;
  box-shadow: 0 12px 32px rgba(0, 0, 0, 0.12);
  padding: 6px;
}
.fpd-container fpd-actions-menu .fpd-dropdown-menu .fpd-btn {
  color: #1e1e1e;
  border-radius: 8px;
  padding: 10px 14px;
}
.fpd-container fpd-actions-menu .fpd-dropdown-menu .fpd-btn:hover {
  background-color: rgba(63, 138, 47, 0.08);
  color: #3f8a2f;
}

/* Element-Toolbar (Farbpopover) — wird via JS an body angehängt, deshalb
 * außerhalb .fpd-container gestylt */
fpd-element-toolbar.fpd-show,
fpd-element-toolbar {
  background: #ffffff !important;
  color: #1e1e1e !important;
  border: 1px solid #e5e7eb !important;
  border-radius: 12px !important;
  box-shadow: 0 12px 32px rgba(0, 0, 0, 0.18) !important;
}
fpd-element-toolbar .fpd-label,
fpd-element-toolbar .fpd-tools-nav > div {
  color: #1e1e1e !important;
}

/* Werkzeugliste (links): Labels sollen UMBRECHEN und zentriert in die schmale
   Spalte passen statt abgeschnitten zu werden + seitliches Scrollen erzeugen
   (Dennis 2026-06-16). */
/* NUR der äußere Scroll-Container darf horizontal kappen. overflow auf
   .fpd-primary-tools/.fpd-secondary-tools setzte implizit overflow-y:auto und
   ließ die Flex-Spalten auf Höhe 0 kollabieren → ALLE Werkzeuge verschwanden
   (Regression, Dennis 2026-06-18). Diese behalten ihre natürliche Höhe. */
fpd-element-toolbar .fpd-tools-nav {
  overflow-x: hidden !important;
}
fpd-element-toolbar .fpd-tools-nav .fpd-label {
  display: block !important;
  white-space: normal !important;
  overflow: visible !important;
  text-overflow: clip !important;
  /* QA 2026-07-02: Silbentrennungs-/Kleinschrift-Workaround ENTFERNT. Die
     Werkzeugleiste ist jetzt 2-spaltig (s.u.), die Spalten sind breit genug:
     Labels in normaler Skin-Größe (11px = FPD-Standard der Tool-Labels) brechen
     NUR noch am Leerzeichen („Größe & Abstand"), nie mehr mitten im Wort —
     „Transformieren"/„Zurücksetzen" passen einzeilig ohne Trennstrich. */
  overflow-wrap: normal;
  word-break: normal;
  hyphens: none;
  text-align: center;
  font-size: 11px !important;
  line-height: 1.2 !important;
  max-width: 100%;
}
/* Einzelne Werkzeuge: volle Spaltenbreite, mittig. Höhe AUTO + genug Platz, damit
   ein 2-zeiliges Label (z.B. „Text bearbeiten") NICHT abgeschnitten wird oder ins
   nächste Werkzeug ragt (Dennis 2026-06-18). KEIN overflow:hidden (schnitt ab).
   :not(.fpd-hidden) ZWINGEND — sonst überschreibt das display:flex !important FPDs
   eigenes „fpd-hidden" (display:none) und zeigt für den Element-Typ irrelevante
   Werkzeuge (z.B. „Erweiterte Bearbeitung"/„Hintergrund entfernen" bei Text). */
fpd-element-toolbar .fpd-primary-tools > div:not(.fpd-hidden),
fpd-element-toolbar .fpd-secondary-tools > div:not(.fpd-hidden) {
  box-sizing: border-box;
  max-width: 100%;
  /* flex-column statt block: nur so addiert der Container Icon- + Label-Höhe sauber
     und wächst (height:auto) mit einem mehrzeiligen Label mit, statt es abzuschneiden. */
  display: flex !important;
  flex-direction: column;
  align-items: center;
  justify-content: flex-start;
  height: auto !important;
  /* Kompakter (Dennis 2026-06-28: „Abstände viel zu groß"): 72→52px. Reicht für ein
     2-zeiliges Label (Icon ~18px + 2×~13px + Innenabstand) und macht die scrollbare
     Werkzeugliste deutlich dichter, sodass mehr Tools auf einmal sichtbar sind. */
  min-height: 52px;
  /* !important nötig: FPD setzt selbst „padding: 0 15px !important" → sonst greift
     der untere Innenabstand nicht und das Label ragt ins nächste Werkzeug. */
  padding: 4px 6px 6px !important;
  text-align: center;
}

/* Werkzeugleiste: DREI Spalten (Paket 9, s. Block unten — vorher ZWEI mit fester
   208px-Breite aus der QA-2026-07-02-Fassung, als die Tool-Nav noch NEBEN einem
   Sub-Panel in der 450px-Sidebar stehen musste). Seit Paket 9 ist die Tool-Nav
   IMMER die einzige Grid-Zelle der vollen Panelbreite (Sub-Panel aktiv → Nav
   komplett ausgeblendet, s. unten) — die alte flex-basis:208px-Bremse ist damit
   gegenstandslos (flex-basis wirkt auf einem Grid-Item ohnehin nicht mehr; die
   Breite kommt jetzt vollständig von der Grid-Area). Live verifiziert
   (2026-07-03, 14-Tool-Fall „Text bearbeiten"): bei voller Panelbreite passen
   auch lange Labels wie „Transformieren"/„Text bearbeiten" einzeilig in 3
   Spalten, macht die Liste spürbar kompakter (5 statt 7 Reihen) ohne
   Silbentrennung. FPD hält die Tools in zwei Containern (.fpd-primary-tools +
   .fpd-secondary-tools); per display:contents lösen wir beide auf, sodass alle
   Tools in EINEM 3-Spalten-Grid der .fpd-tools-nav fließen. minmax(0,1fr)
   verhindert, dass ein langes Einwort-Label seine Spalte aufbläht. Spezifität
   (#fpd-host …) gewinnt ohne !important. Greift NUR die docked Variante; das
   mobile body-Bottom-Sheet (eigene Regeln unten) bleibt unberührt. */
#fpd-host fpd-element-toolbar .fpd-tools-nav {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  align-content: start;
  gap: 2px;
}
#fpd-host fpd-element-toolbar .fpd-primary-tools,
#fpd-host fpd-element-toolbar .fpd-secondary-tools {
  display: contents;
}
/* Historisch (vor Paket 9): das Sub-Panel musste neben der 2-Spalten-Tool-Nav
   (208px) in den Rest der Sidebar passen, seine min-width:auto (= min-content
   der Palette) blockierte das Flex-Shrink → es lief über die Toolbar hinaus
   und wurde rechts abgeschnitten. Seit Paket 9 bekommt das Sub-Panel die volle
   Panelbreite für sich allein (Tool-Grid ist in diesem Zustand komplett
   ausgeblendet, s. Block unten) — min-width:0 bleibt trotzdem als genereller
   Grid-Item-Shrink-Fix bestehen (schadet nicht, könnte bei künftig sehr
   schmalen Viewports wieder relevant werden). */
#fpd-host fpd-element-toolbar .fpd-sub-panel {
  min-width: 0;
}

/* ══════════════════════════════════════════════════════════════════════════
   Paket 8 (Dennis 2026-07-02): „Bearbeiten-Panel in voller Spalte" — Rückbau
   von Paket 5/6/7 + QA-Mangel-3 (die drei bauten einen „Override-Turm": erst
   die Sub-Panel-Spalte ausblenden, dann die Karten-Optik auf ein schrumpfendes
   Tool-Grid verlagern, dann dessen Höhe wieder einfangen — jede Stufe reagierte
   nur auf die vorherige). Dennis' Entscheidung (Zitat-Paraphrase): die
   schwebende, mal große mal kleine Karte „gehört da nicht hin", verdeckt das
   Modul-Panel. Neues Zielbild: die Element-Toolbar FÜLLT die 450px-Spalte
   GENAUSO wie das Modul-Panel — volle Breite/Höhe, IMMER (nicht mehr
   fit-content/collapsed) — mit einer Kopfzeile (Titel + immer sichtbares ✕ =
   Voll-Deselect, injiziert via FPDDesigner.tsx) und einem „← Zurück" statt des
   bisherigen X fürs Sub-Panel (das X ist jetzt der Kopfzeile vorbehalten).

   DOM-Beleg (Live-Test 2026-07-02, https://banasport2026.scpreview.de/designer,
   1280×800, echtes Text-Element selektiert): fpd-element-toolbar hat GENAU 4
   Kinder — .fpd-close-sub-panel, .fpd-close, .fpd-tools-nav, .fpd-sub-panel
   (Paket 5's Befund bestätigt). NEU verifiziert: .fpd-close ist FPDs ECHTES
   Voll-Schließen-X (innerHTML `<span class="fpd-icon-close">`), im Desktop-
   Layout aber nativ `display:none` (FPD zeigt es nur im Small/Mobile-Layout).
   Erzwungen sichtbar + geklickt: es setzt lediglich `fpd-show` auf der Toolbar
   zurück (Toolbar verschwindet, zurück zum Modul-Panel) — das Canvas-Element
   BLEIBT dabei fabric-seitig selektiert (Griffe blieben nach dem Klick auf der
   Stage sichtbar). Das ist NICHT dasselbe wie ein vollständiges Deselect und
   reicht für die Kopfzeilen-✕-Anforderung (Punkt C, „IMMER vollständiges
   Deselect, dieselbe deselectElement()-Funktion wie Paket 7a") nicht aus.
   Fix: .fpd-close bleibt daher dauerhaft ausgeblendet; die Kopfzeile wird
   komplett eigen injiziert (FPDDesigner.tsx, Muster wie injectCenterButton/
   injectLoginBadge) und ihr ✕ ruft explizit fpdRef.current.deselectElement()
   auf (identische Funktion wie Paket 7a).

   Sub-Panel-Anordnung: NEBENEINANDER (Variante a), nicht „ersetzt Tool-Grid"
   (Variante b). Begründung: FPD hält .fpd-tools-nav und .fpd-sub-panel als
   ECHTE, unabhängige Geschwister-Kinder von fpd-element-toolbar (kein
   gemeinsamer Wrapper im DOM) und schaltet zwischen 2/12-Tool-Zuständen rein
   über :has()/.fpd-active, ohne die beiden je zu vertauschen — ein „ersetzt"-
   Layout hätte eine JS-seitige DOM-Umsortierung (Kinder zwischen zwei Wrappern
   verschieben) gebraucht, mit Race-Risiko gegen FPDs eigenen Toolbar-Rebuild
   bei jeder Neu-Selektion (s. MutationObserver-Kommentar weiter unten in
   FPDDesigner.tsx). CSS Grid mit festen Areas („hdr hdr" / „nav sub") erreicht
   dieselbe Optik rein deklarativ, ohne ein einziges Element zu verschieben —
   robuster, kein neuer Angriffspunkt für Regressionen. Live an echtem Text-
   Element und echter Farbzone verifiziert (Screenshots 2026-07-02): Kopfzeile
   oben volle Breite, darunter Tool-Grid (208px) + Sub-Panel (Rest) sauber
   nebeneinander, kein Überlapp mit den Panel-Tabs („Farbe/Umrandung/Schatten").

   Karten-Optik: das Modul-Panel (fpd-main-bar, live gemessen) ist FLACH — kein
   border-radius, kein box-shadow, nur background:#fff (via .fpd-module-content-
   Override, s. Regeln oben) + ein dünner border-right. „Gleiche Optik wie das
   Modul-Panel" heißt hier also: border-radius:0, box-shadow:none — NICHT die
   frühere schwebende Rundkarte mit Schatten (das war gerade das Symptom, das
   Dennis abgestellt haben wollte). Weiß + Border bleiben (wie gefordert).

   Was von Paket 5/6/7 übrig bleibt vs. entfernt wird:
   - Paket 5 (Sub-Panel+X ausblenden, wenn kein Kind aktiv): ENTFERNT. Die
     Prämisse (leere Spalte = totes Weißraum-Problem) gilt nicht mehr — die
     Karte ist jetzt IMMER voll, leerer Sub-Panel-Bereich ist so normal wie ein
     Modul-Panel mit wenig Inhalt (z. B. Farbzone: nur 2 Tools, Sub-Panel zeigt
     trotzdem direkt die Farbpalette, da FPD sie automatisch aktiviert).
   - Paket 6 (Karte auf .fpd-tools-nav verlagern, Toolbar transparent/
     fit-content): ENTFERNT. Widerspricht dem neuen Zielbild direkt (Toolbar
     soll IMMER volle Breite/Höhe tragen, nicht schrumpfen).
   - Paket 7 (.fpd-tools-nav align-self:flex-start + height:auto im
     eingeklappten Zustand): ENTFERNT zusammen mit Paket 6 (derselbe
     :not(:has(...))-Zustand existiert im neuen Zielbild nicht mehr — die Karte
     kollabiert nie). Der separate Zitter-Fix weiter unten („Punkt 2 — die
     scrollbare VERTIKALE Werkzeugliste", max-height: calc(100% - 12px)) ist
     UNABHÄNGIG davon und bleibt unverändert bestehen (wird hier nicht
     angefasst) — er kappt die Nav-Höhe unabhängig vom Sub-Panel-Zustand.
   - QA-Mangel-3-X (.fpd-close-sub-panel als reines ✕ oben rechts im Panel):
     ENTFERNT/ERSETZT. Das ✕ ist jetzt der Kopfzeile vorbehalten (Punkt 2 der
     Aufgabe); .fpd-close-sub-panel zeigt wieder FPDs eigenes Back-Icon +
     „Zurück"-Label (nicht mehr per CSS versteckt) und wandert als eigene Zeile
     ÜBER die Panel-Tabs (statt absolut in der Ecke zu schweben und die Tabs zu
     überlappen, s. DOM-Beleg oben). Klickverhalten bleibt FPDs natives „eine
     Ebene zurück" (Sub-Panel schließt, Element bleibt selektiert) — siehe
     Paket 7a-Kommentar in FPDDesigner.tsx zur JS-Seite dieser Entscheidung.
   - .fpd-sub-panel { min-width:0 } (Zeile ~423): bleibt unverändert (Grid-Item-
     Shrink-Fix, unabhängig vom Rest weiter gültig).
   ══════════════════════════════════════════════════════════════════════════ */

/* ══════════════════════════════════════════════════════════════════════════
   Paket 9 (Dennis 2026-07-03): „Drill-Down — eine Ebene, volle Breite" — engt
   Paket 8s NEBENEINANDER-Layout (Tool-Grid 208px fest + Sub-Panel im Rest,
   direkt darunter dokumentiert) ein. Dennis' QA zu Paket 8 (Live-Screenshots):
   „noch schlechter als vorher" — Tool-Grid und Sub-Panel teilten sich die
   450px-Spalte, die Farbpalette wurde auf 3 Swatches/Reihe gequetscht und das
   HEX-Feld rechts angeschnitten, während links vom Tool-Grid viel Leerfläche
   blieb. Paket 8s Nebeneinander-Begründung (zwei echte, unabhängige FPD-
   Geschwisterkinder ohne DOM-Umbau lösbar) bleibt technisch richtig — nur die
   Entscheidung „beide gleichzeitig anzeigen" wird hier zurückgenommen.

   Neues Zielbild: nur EINE Ebene gleichzeitig sichtbar, beide in VOLLER
   Panelbreite. Kein aktives Sub-Panel → Tool-Grid füllt die ganze Breite
   (durfte dafür laut Dennis "gern breiter atmen oder 3-spaltig werden" — live
   verifiziert 2026-07-03 mit dem 14-Tool-Fall "Text bearbeiten": in 3 Spalten
   passen auch lange Labels wie „Transformieren"/„Text bearbeiten" einzeilig,
   5 statt 7 Reihen, s. `.fpd-tools-nav`-Regel weiter oben). Sub-Panel aktiv →
   Tool-Grid KOMPLETT ausgeblendet (`display:none`, kein Platz-Kompromiss mehr),
   „← Zurück" + Sub-Panel-Inhalt füllen die volle Breite. Rein deklarativ per
   Zustandswechsel über `:has(.fpd-sub-panel > .fpd-active)` — exakt der
   Selektor, den Paket 8.1 schon für die Zurück-Sichtbarkeit einführte (s.
   QA-Mangel-2-Kommentar weiter unten, dort jetzt auf den einzig verbliebenen
   Zweck „Grid-Area existiert im Basis-Zustand nicht, Element bräuchte sonst
   eigenes display:none" reduziert).

   Live verifiziert (2026-07-03, Style-Injektion + Screenshots am Live-Build,
   https://banasport2026.scpreview.de/designer, 1280×800/1000): Trikot-Farbzone
   (2 Tools, FPD aktiviert die Palette automatisch → Sub-Panel-Zustand direkt
   beim Selektieren) — Palette 4 Swatches/Reihe statt 3, HEX-Feld + OK-Button
   komplett sichtbar, kein Leerraum links. Text-Element (14 Tools) — Basis-
   Zustand 3-spaltiges Tool-Grid, alle Sub-Panels (Farbe/Palette, Schriftart-
   Suche+Liste, Format, Größe & Abstand-Slider, Anordnung, Bogen-Presets) je
   volle Breite ohne Überdehnung/Clipping. Übergänge Farbe→Zurück→Schriftart→
   Zurück→Bogen (Preset-Klick lässt FPD selbst auf die Farbpalette umspringen —
   unser generischer `:has()`-Selektor greift das ab, ohne den Sub-Panel-Typ zu
   kennen) → Kopfzeilen-✕ (Voll-Deselect zurück zum Modul-Panel) — alle sauber,
   kein Stage-Sprung (Sidebar-Spalte bleibt während des gesamten Tests exakt
   konstant breit, Grid-Area „bs-hdr/bs-nav/bs-back/bs-sub" ändert nur die
   INNERE Aufteilung, nie die Spaltenbreite der Sidebar selbst).
   ══════════════════════════════════════════════════════════════════════════ */

/* Grundgerüst: Toolbar als CSS-Grid mit 1 Spalte (Kopfzeile + darunter GENAU
   eine Ebene — Tool-Grid ODER „← Zurück"+Sub-Panel, nie beide gleichzeitig,
   s. Paket-9-Kommentar oben) statt FPDs eigenem `display:flex; flex-direction:
   row`. width/height:100% (statt FPDs eigenem `width/height:100% !important`
   auf fpd-main-bar > fpd-element-toolbar, das ohnehin schon exakt das leistet
   — hier nur zur Robustheit explizit gesetzt, falls FPD die Regel je ändert)
   füllt die Sidebar-Spalte inkl. voller Höhe, GENAU wie ein Modul-Panel.
   position:static ersetzt FPDs eigenes position:absolute (unnötig, sobald die
   Toolbar ohnehin die ganze Grid-Zelle ausfüllt — vermeidet zusätzliche
   Stacking-Context-Überraschungen mit der Kopfzeile). Karten-Optik flach wie
   fpd-main-bar (s. Kommentar oben): kein radius/shadow, nur weißer Grund +
   Border.
   WICHTIG (Live-Regression gefunden + gefixt 2026-07-02, weiter gültig):
   `.fpd-show` PFLICHT im Selektor. FPD blendet die Toolbar über genau diese
   Klasse ein/aus (Basis-CSS: `fpd-element-toolbar{display:none}`, `.fpd-show
   {display:flex}`). Ein erster Entwurf ohne `.fpd-show` im Selektor erzwang
   `display:grid !important` UNBEDINGT — die Toolbar blieb dadurch permanent
   sichtbar/interaktiv, selbst nachdem FPD (oder unser eigener
   deselectElement()-Aufruf) `fpd-show` bereits entfernt hatte (live
   verifiziert: className ohne `fpd-show`, computedDisplay trotzdem `grid`).
   Mit `.fpd-show` im Selektor greift unser Grid-Layout NUR, wenn FPD die
   Toolbar ohnehin zeigen will; ohne die Klasse gewinnt FPDs eigene
   `display:none`-Regel wieder (kein Konflikt, da unsere Regel dann gar nicht
   matcht).
   Basis-Zustand (Standard-Regel, kein aktives Sub-Panel-Kind): 2 Zeilen,
   „bs-nav" nimmt die komplette Fläche unter der Kopfzeile ein. „bs-back" und
   „bs-sub" tauchen hier bewusst NICHT in den Areas auf — die zugehörigen
   Elemente bleiben über eigene display:none-Regeln unten ausgeblendet (s.
   `.fpd-close-sub-panel`- und `.fpd-sub-panel`-Sichtbarkeitsregeln). */
#fpd-host fpd-element-toolbar.fpd-show {
  display: grid !important;
  grid-template-columns: 1fr !important;
  grid-template-rows: auto 1fr !important;
  grid-template-areas: "bs-hdr" "bs-nav" !important;
  width: 100% !important;
  height: 100% !important;
  position: static !important;
  background-color: #ffffff !important;
  border: none !important;
  border-radius: 0 !important;
  box-shadow: none !important;
}
/* Sub-Panel-Zustand: Tool-Grid komplett raus, „← Zurück" bekommt seine eigene
   Zeile über dem Sub-Panel-Inhalt, beide in voller Breite. Eigener Selektor
   (nicht in die Basis-Regel oben gemischt) hält beide Zustände klar getrennt
   lesbar und vermeidet einen dritten „doppelt reagierenden" Override-Schritt
   (s. Paket-8-Rückblick oben, „Override-Turm"-Warnung).
   Paket 9.1 (Dennis 2026-07-03, Bug „Grid+Sub-Panel gleichzeitig sichtbar"):
   Zustandserkennung von `:has(.fpd-sub-panel > .fpd-active)` auf das
   JS-gepflegte Attribut `[data-bs-sub]` umgestellt (FPDDesigner.tsx,
   syncToolbarState() im run()-Zyklus, direkt neben injectToolbarHeader/
   capNavHeight — identisches Muster: nur docked Desktop, nur schreiben wenn
   der Wert sich ändert). Herleitung: `:has()` muss bei JEDER Subtree-Mutation
   unter fpd-element-toolbar neu ausgewertet werden; FPD baut die Toolbar bei
   jeder Neu-Selektion komplett neu auf (s. Kommentar „FPD die Toolbar bei
   jeder Neu-Selektion komplett neu aufbaut" weiter unten in dieser Datei) —
   DOM-Rebuild und das Setzen von `.fpd-active` auf dem neuen Sub-Panel-Kind
   laufen dabei NICHT atomar. Reproduktion (2 Runden automatisiertes Fuzzing,
   Farbe/Schriftart/Bogen-Wechsel + Bogen-Preset-Sprung + Undo/Redo + schnelle
   Neu-Selektion, teils 5ms-Taktung) hat den Bruch live nicht ausgelöst (0
   Verletzungen bei >1200 Checks) — deckt sich mit „sporadisch, nicht
   zuverlässig reproduzierbar". Optik/Areas bleiben exakt gleich, nur der
   Trigger-Mechanismus ist jetzt ein expliziter, von uns kontrollierter
   DOM-Write statt CSS-Selektor-Timing. */
#fpd-host fpd-element-toolbar.fpd-show[data-bs-sub] {
  grid-template-rows: auto auto 1fr !important;
  grid-template-areas: "bs-hdr" "bs-back" "bs-sub" !important;
}
/* Tool-Grid im Sub-Panel-Zustand vollständig ausgeblendet (nicht nur auf 0
   geschrumpft) — s. Paket-9-Begründung oben: kein Platz-Kompromiss mehr,
   Sub-Panel bekommt die komplette Breite. */
#fpd-host fpd-element-toolbar.fpd-show[data-bs-sub] > .fpd-tools-nav {
  display: none !important;
}
/* Kopfzeile (JS-injiziert, FPDDesigner.tsx: injectToolbarHeader) — volle
   Panelbreite, Titel links + ✕ rechts (Voll-Deselect). */
#fpd-host fpd-element-toolbar > .bs-toolbar-header {
  grid-area: bs-hdr;
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 8px;
  padding: 12px 16px;
  border-bottom: 1px solid #e5e7eb;
  box-sizing: border-box;
}
#fpd-host fpd-element-toolbar > .bs-toolbar-header .bs-toolbar-title {
  font-size: 14px;
  font-weight: 600;
  color: #1e1e1e;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
}
#fpd-host fpd-element-toolbar > .bs-toolbar-header .bs-toolbar-close {
  flex: 0 0 auto;
  display: flex;
  align-items: center;
  justify-content: center;
  width: 28px;
  height: 28px;
  border-radius: 8px;
  cursor: pointer;
  color: #6b7280;
  font-size: 15px;
  font-weight: 700;
  line-height: 1;
  background: transparent;
  border: none;
}
#fpd-host fpd-element-toolbar > .bs-toolbar-header .bs-toolbar-close:hover {
  color: #c6000f;
  background-color: rgba(198, 0, 15, 0.08);
}
/* Tool-Grid + Sub-Panel: eigene Grid-Areas statt Flex-Reihenfolge im Elternteil
   — beide bleiben echte, unverschobene FPD-Kinder (s. Begründung oben). Seit
   Paket 9 existiert „bs-sub" nur noch im Sub-Panel-Zustand (s. :has()-Regel
   oben) — im Basis-Zustand hat .fpd-sub-panel schlicht keine passende Area
   mehr und bekäme sonst eine implizite Auto-Placement-Zeile; das ist in der
   Praxis unsichtbar, weil FPD dem Element in diesem Zustand ohnehin kein
   .fpd-active-Kind gibt (leerer Container, keine eigene Höhe) — trotzdem KEIN
   explizites display:none nötig (anders als bei „bs-back"/.fpd-close-sub-panel
   unten, das FPD permanent mit Inhalt befüllt hält). */
#fpd-host fpd-element-toolbar > .fpd-tools-nav {
  grid-area: bs-nav;
}
#fpd-host fpd-element-toolbar > .fpd-sub-panel {
  grid-area: bs-sub;
  min-height: 0;
}
/* FPDs natives Voll-Schließen-X bleibt ausgeblendet (s. DOM-Beleg oben: schließt
   die Toolbar NICHT über ein echtes fabric-Deselect) — die injizierte
   Kopfzeile übernimmt diese Rolle vollständig. */
#fpd-host fpd-element-toolbar > .fpd-close {
  display: none !important;
}
/* „← Zurück" (eine Ebene zurück, schließt NUR das Sub-Panel — s. Paket-7a-
   JS-Kommentar): EIGENE Grid-Zeile (bs-back) über dem Sub-Panel-Inhalt statt
   absolut in der Ecke (das frühere QA-Mangel-3-X überlappte dort die Panel-
   Tabs) UND statt nur `order:-1` (Live-Test 2026-07-02 belegt: `order` ordnet
   nur unter Geschwistern der GLEICHEN Auto-Placement-Basis — ohne explizite
   grid-area landete das Element in einer impliziten 3. Zeile unter dem
   Tool-Grid, weit weg vom Sub-Panel; grid-area:bs-back behebt das). FPDs
   eigenes Back-Icon + „Zurück"-Label werden NICHT mehr per CSS versteckt (das
   war QA-Mangel-3s Ersatz-✕, jetzt entfernt) — sie sind bereits ein klar
   erkennbares, vom Kopfzeilen-✕ unterscheidbares Zurück-Symbol.
   QA-Mangel-2 (Paket 8.1, Dennis 2026-07-02): Live-DOM-Beleg (Sub-Panel offen →
   „← Zurück" geklickt) — FPD entfernt `.fpd-active` zuverlässig vom vormals
   aktiven Kind in `.fpd-sub-panel` (verifiziert: hasActiveChild wechselt
   true→false), lässt `.fpd-close-sub-panel` selbst aber unangetastet
   (computedDisplay blieb `flex`) — unsere eigene `display:flex !important`-
   Regel oben kennt diesen Zustand nicht und zeigt die Zeile daher permanent,
   bis ein neues Tool `.fpd-active` neu setzt. Fix: bestehende Regel um ein
   `:not(:has(...))` am Toolbar-Wurzelelement einengen (kein neuer
   !important-Turm) — zeigt die Zurück-Zeile nur, wenn ein Sub-Panel-Kind
   `.fpd-active` trägt.
   Paket 9 (Dennis 2026-07-03): dieselbe Regel bekommt einen ZWEITEN, jetzt
   noch wichtigeren Zweck — im neuen Basis-Grid (kein aktives Sub-Panel) gibt
   es gar keine „bs-back"-Area mehr (s. Grundgerüst-Regel oben, Areas nur noch
   "bs-hdr" "bs-nav"). Ohne dieses display:none würde .fpd-close-sub-panel
   trotzdem (FPD hält es permanent im DOM) per CSS-Grid-Auto-Placement in einer
   impliziten Zeile unter dem Tool-Grid auftauchen. Die Regel bleibt daher
   bestehen, ist die einzige Absicherung gegen zwei unterschiedliche
   Fehlerquellen (Paket-8.1-Altzustand UND Paket-9-fehlende Area) statt nur
   einer.
   Paket 9.1 (Dennis 2026-07-03): `:not(:has(.fpd-sub-panel > .fpd-active))`
   durch `:not([data-bs-sub])` ersetzt — selbe Begründung/selber Mechanismus
   wie beim Grundgerüst-Selektor oben (JS-gepflegtes Attribut statt
   :has()-Timing, s. dortiger Kommentar für die volle Herleitung). */
#fpd-host fpd-element-toolbar.fpd-show:not([data-bs-sub]) > .fpd-close-sub-panel {
  display: none !important;
}
#fpd-host fpd-element-toolbar > .fpd-close-sub-panel {
  display: flex !important;
  grid-area: bs-back !important;
  position: static !important;
  transform: none !important;
  width: 100% !important;
  min-width: 0 !important;
  height: auto !important;
  padding: 8px 10px !important;
  gap: 6px;
  align-items: center;
  justify-content: flex-start;
  border-bottom: 1px solid #e5e7eb;
  color: #6b7280;
  font-size: 12px;
}
#fpd-host fpd-element-toolbar > .fpd-close-sub-panel:hover { color: #3f8a2f; }
#fpd-host fpd-element-toolbar > .fpd-close-sub-panel .fpd-icon-back,
#fpd-host fpd-element-toolbar > .fpd-close-sub-panel .fpd-label {
  display: inline-flex;
}

/* ══════════════════════════════════════════════════════════════════════════
   Paket 9.2 (Dennis 2026-07-03): „Sub-Panel-Scroll bei kleiner Fensterhöhe" —
   Live-Befund (2 Screenshots, kleiner Bildschirm; live nachgestellt via Chrome-
   MCP, innerHeight ~417px bereits ohne künstliche Verkleinerung real erreicht,
   #fpd-host height:440px per clamp()): im Farbe-Panel war „Transparenz" unten
   abgeschnitten, im Schatten-Panel „Weichzeichnung" + Offsets — kein
   Scrollbalken, kein Scrollen möglich, trotz vorhandenem Platz-Budget aus der
   Paket-9-Grid-Zeile „1fr" (bs-sub, s. Grundgerüst-Regeln oben).

   Overflow-Kette live vermessen (getComputedStyle, Text-Element, Farbe- UND
   Schatten-Tab, jeweils .fpd-panel-color.fpd-active — FPD nutzt denselben
   Wrapper für beide Tabs, „Schatten" ist technisch nur ein zweiter Tab-Inhalt
   mit eigener Farbwahl + Blur/Offset-Reglern):
     .fpd-sub-panel                     h=296px (korrekt: Paket-9-Grid-Zeile)
       .fpd-panel-color.fpd-active      h=296px, overflow-y:VISIBLE, scrollH=380/582
         .fpd-panel-tabs                h=34px  (Tab-Leiste „Farbe"/„Schatten")
         .fpd-panel-tabs-content
           .fpd-scroll-area             h=296px, overflow-y:VISIBLE (!), scrollH=336/538
           .fpd-active                  h=328px/530px  ← tatsächlicher Inhalt,
                                           höher als die 296px verfügbare Höhe
             .fpd-color-wrapper / .fpd-shadow-color-wrapper  (Palette+HEX)
             .fpd-tool-fill-opacity     ← „Transparenz" (Farbe-Tab)
             .fpd-tool-shadow-blur/-offsetX/-offsetY  ← „Weichzeichnung“+Offsets (Schatten-Tab)
   Befund: FPD MARKIERT seinen eigenen Scroll-Wrapper bereits korrekt mit der
   Klasse „fpd-scroll-area" (.fpd-panel-tabs-content.fpd-scroll-area) — genau
   die Konvention, die an anderer Stelle in dieser Datei bereits gilt (Farben-/
   Bilder-/Designs-Module, Werkzeugliste, Schriftart-Dropdown-Liste, s.
   Kommentare weiter oben). NUR bei diesem einen Wrapper-Typ
   (.fpd-panel-color, von FPD für Farbe UND Schatten wiederverwendet) bleibt
   FPDs eigenes overflow-y auf „visible" statt „auto" — andere Sub-Panel-Typen
   (.fpd-panel-font-family, .fpd-panel-position, .fpd-panel-advanced-editing)
   wurden live gegengeprüft und lösen ihr .fpd-scroll-area bzw. .fpd-panel-
   tabs-content bereits nativ zu overflow-y:auto auf — dort ist kein Fix nötig,
   folglich auch kein Risiko einer Doppel-Regression.
   Fix-Ansatz: NUR dieses eine, bereits von FPD als Scroll-Container markierte
   Element umschalten (overflow-y:auto) + die Flex-Kette bis dorthin auf
   min-height:0 setzen, damit der Flex-Child (.fpd-panel-color.fpd-active,
   display:flex/column) bei zu hohem Inhalt SCHRUMPFT statt zu wachsen (Flex-
   Default ist min-height:auto = Inhaltshöhe, das genaue Gegenteil von dem, was
   hier gebraucht wird). Scope ausschließlich auf den Drill-Down-Zustand
   (fpd-show[data-bs-sub], Paket-9.1-Attribut) UND #fpd-host — Mobile
   (body > fpd-element-toolbar, eigener Block unten) bleibt unberührt.
   KEIN Doppel-Scroll: die Fontliste (.fpd-panel-font-family .fpd-scroll-area,
   max-height:200px, s. eigene Regel weiter unten in dieser Datei) sitzt in
   einem STRUKTURELL ANDEREN Sub-Panel-Typ ohne den hier gefixten
   .fpd-panel-tabs-content-Wrapper — von dieser Regel unberührt, live
   gegengeprüft (kein verschachtelter zweiter Scrollbalken).
   Verifiziert (2026-07-03, Chrome-MCP, #fpd-host height 440px UND 386px via
   Style-Injektion, Farbe- UND Schatten-Tab, Text- UND Bild-Element): Palette+
   HEX+Transparenz vollständig erreichbar (scrollTop bis scrollHeight-clientHeight
   ohne Rest), Weichzeichnung+beide Offset-Regler+„Schatten entfernen"-Button
   vollständig erreichbar, kein zweiter/verschachtelter Scrollbalken, bei großer
   Höhe (800px) kein unnötiger Scrollbalken (Inhalt passt, overflow bleibt
   inaktiv weil scrollHeight <= clientHeight).

   NACHTRAG Paket 9.2.1 (Dennis 2026-07-03, Live-QA am DEPLOYTEN Build): Dennis
   meldet mit Screenshot weiterhin abgeschnittenes „Transparenz" trotz Deploy
   dieses Fixes. Live-Beleg (Chrome-MCP, neuer Tab, location.reload(true),
   https://banasport2026.scpreview.de/designer, Text-Element, Farbe-Tab):
   - Die Regel ist im ausgelieferten Bundle vorhanden UND unverändert (Diff
     gegen den geladenen Stylesheet-Text: exakt dieser Selektor + exakt diese
     zwei Deklarationen, an derselben Stelle) — KEIN Cache-/Bundle-Problem.
   - getComputedStyle auf .fpd-panel-tabs-content.fpd-scroll-area ergab
     trotzdem overflow-y:VISIBLE, nicht auto. Ursache gefunden: FPDs eigenes
     Vendor-CSS (separates <link>-Sheet, LÄDT NACH unserem fpd-brand.css)
     enthält `fpd-element-toolbar .fpd-sub-panel .fpd-panel-color >
     .fpd-scroll-area { overflow: visible }` — Spezifität (0,3,1), unsere
     Regel `#fpd-host fpd-element-toolbar.fpd-show[data-bs-sub]
     .fpd-panel-tabs-content.fpd-scroll-area { overflow-y: auto }` hat
     rechnerisch HÖHERE Spezifität (1,4,1 dank #fpd-host). Nach reinem
     CSS-Spezifitäts-Standard müsste unsere ID-Regel unabhängig von der
     Ladereihenfolge gewinnen — live gewinnt sie aber nachweislich NICHT
     (verifiziert per Injektions-Test: ein zusätzliches <style>-Tag mit
     IDENTISCHEM Selektor, garantiert später im Dokument eingehängt, OHNE
     !important blieb wirkungslos; dieselbe Regel MIT !important griff sofort
     und machte den Bereich korrekt scrollbar). Diese Diskrepanz zwischen
     erwarteter Spezifitäts-Kaskade und beobachtetem Ergebnis wird hier nicht
     weiter aufgeklärt (möglliche Erklärungen: Next.js' Head-Manager greift in
     die style/link-Reihenfolge ein und dupliziert/versetzt Sheets zur
     Laufzeit anders als beim Server-Render, mit Rückwirkung auf die
     Kaskaden-Auswertung; oder ein Timing-Effekt beim Custom-Element-Rebuild
     von fpd-element-toolbar) — der Befund ist aber am Live-Build reproduzierbar
     belegt, daher pragmatischer Fix: !important auf overflow-y, die einzige
     Deklaration, die tatsächlich im Streit mit FPDs Regel steht (min-height
     hat keine konkurrierende FPD-Regel und bleibt unangetastet). Erneut live
     verifiziert (2026-07-03, Farbe- UND Schatten-Tab, #fpd-host height 452px
     [Fenster 1300×780, Dennis' gemeldete Größe] UND 386px): overflow-y jetzt
     zuverlässig „auto", Transparenz/Weichzeichnung/Offsets/„Schatten
     entfernen" vollständig erreichbar per Scroll, kein zusätzlicher
     Seiten-Scroll nötig, kein doppelter Scrollbalken, große Höhe (800px)
     weiterhin ohne unnötigen Scrollbalken (unverändert, !important ändert
     nichts an der Bedingung selbst — overflow bleibt inaktiv wenn
     scrollHeight <= clientHeight, unabhängig von !important). */
#fpd-host fpd-element-toolbar.fpd-show[data-bs-sub] .fpd-sub-panel > .fpd-active {
  min-height: 0;
}
#fpd-host fpd-element-toolbar.fpd-show[data-bs-sub] .fpd-panel-tabs-content.fpd-scroll-area {
  min-height: 0;
  overflow-y: auto !important;
}

/* ══════════════════════════════════════════════════════════════════════════
   Paket 9.2.2 (Dennis 2026-07-03): „Mausrad über der Farbpalette scrollt
   nicht" — Dennis meldet: Scrollen funktioniert nur, wenn der Zeiger UNTER
   den Farbfeldern steht (über HEX/Transparenz), nicht wenn er ÜBER dem
   Farbfelder-Bereich (Palette) steht.

   Live-Beleg (Chrome-MCP, echtes Text-Element, Farbe-Tab, #fpd-host 452px):
   elementFromPoint an der obersten Swatch-Reihe (y≈400, direkt unter der
   „Farbe/Schatten"-Tableiste) landet in EINER ZWEITEN, bisher unentdeckten
   verschachtelten .fpd-scroll-area — NICHT der schon gefixten
   .fpd-panel-tabs-content.fpd-scroll-area von oben, sondern eine innere
   Instanz direkt um die Palette: `.fpd-color-panel > .fpd-scroll-area`
   (FPD-eigenes CSS: `.fpd-container .fpd-color-panel > .fpd-scroll-area
   { height:auto; max-height:100px; margin-bottom:10px }` — OHNE eigenes
   overflow, erbt daher die BASIS-Regel `.fpd-container .fpd-scroll-area
   { overflow:auto; overscroll-behavior:none }`, die FPD auf JEDES Element
   mit der Klasse `fpd-scroll-area` anwendet, unabhängig davon ob dessen
   Inhalt tatsächlich überläuft). scrollHeight/clientHeight dieser inneren
   Area sind praktisch identisch (122px/122px – nicht scrollbar), sie ist
   also nie sichtbar aktiv, bleibt aber ein ECHTER CSS-Scroll-Container
   (overflow:auto erzeugt eine Scroll-Box auch ohne Overflow-Inhalt) und
   nimmt dem Browser die Wheel-Scroll-Entscheidung an dieser Stelle ab, statt
   sie an den echten Scroller (.fpd-panel-tabs-content) weiterzureichen.
   Tiefer in der Palette (Reihe 2–4, y≈460+) liegt der Zeiger dagegen schon
   außerhalb der Bounding-Box dieser inneren Area (122px hoch, endet kurz
   nach Reihe 1) → dort traf der Bug nicht, was Dennis' Beschreibung exakt
   erklärt („nur über den Farbfeldern", nicht irgendwo im Panel).

   Standard-Fix in dieser Datei ist bislang `overflow-y:visible !important`
   (s. Feedback-2026-06-12-Regel weiter unten, Zeile ~1500) — die deckt genau
   diesen Selektor (`.fpd-color-panel .fpd-scroll-area`) BEREITS ab, ändert
   aber nur die Y-Achse. Live-Test (Chrome-MCP, getComputedStyle direkt an
   der beim Klick tatsächlich getroffenen Instanz, nicht nur per Selektor-
   Match): overflow-x blieb dabei `auto` (von FPDs Basis-Regel geerbt) →
   nach CSS-Overflow-Spec wird overflow-y dadurch trotz `visible` zu `auto`
   BERECHNET, sobald overflow-x einen Scroll-Wert hat und overflow-y nicht
   (dieselbe Falle, die Zeile ~1515 dieser Datei für ein anderes Element schon
   dokumentiert: „overflow-x:hidden macht overflow-y trotz visible effektiv
   zu auto"). Kein Spezifitäts-/Ladereihenfolge-Problem (Kontrollversuch:
   dieselbe Regel mit `background-color`/`border` statt `overflow-y` griff
   sofort) — reiner Verbund-Effekt der beiden Overflow-Achsen.
   Fix: `overflow` (Shorthand, setzt BEIDE Achsen auf `visible`) statt nur
   `overflow-y`. Scope identisch zu den anderen Paket-9.2-Regeln oben
   (#fpd-host, [data-bs-sub], NUR der docked Desktop-Zustand) UND zusätzlich
   auf `> .fpd-scroll-area` (direktes Kind) verengt, NICHT den Nachfahren-
   Kombinator der alten Zeile-~1500-Regel — die alte Regel matcht mit
   `.fpd-color-panel .fpd-scroll-area` (Leerzeichen) auch
   `.fpd-panel-tabs-content.fpd-scroll-area` selbst (der äußere, ECHTE
   Scroller ist strukturell ein Nachfahre von `.fpd-panel-color`, das
   `.fpd-color-panel` als Kind-Selektor-Fragment ebenfalls trifft) und hätte
   dessen `overflow-y:auto` aus der Regel direkt oberhalb wieder aufgehoben,
   wodurch GAR NICHTS mehr scrollt (live verifiziert: mit dem Nachfahren-
   Selektor wurde `.fpd-panel-tabs-content.fpd-scroll-area` selbst zu
   `overflow:visible` — der einzige Scroller wäre komplett deaktiviert
   gewesen). `>` (direktes Kind) trifft nur die innere, nicht scrollbare
   Area und lässt den äußeren Scroller unangetastet.
   Verifiziert (2026-07-03, Chrome-MCP, echte OS-Level-Wheel-Events über
   Computer-Tool, #fpd-host 452px, Text-Element, Farbe-Tab): Der verschach-
   telte Phantom-Scroll-Container ist nachweislich beseitigt — getComputedStyle
   zeigt auf `.fpd-color-panel > .fpd-scroll-area` jetzt `overflow-x:visible`
   UND `overflow-y:visible` (beide Achsen), der äußere ECHTE Scroller
   `.fpd-panel-tabs-content.fpd-scroll-area` bleibt unangetastet bei
   `overflow-y:auto`. Swatch-Klick wählt weiterhin zuverlässig die Farbe
   (Klick-Funktionalität unverändert). Kein Regressions-Fall gefunden, in dem
   der äußere Scroller durch diese Regel deaktiviert würde.
   OFFEN / NICHT vollständig gelöst: Der ursprünglich gemeldete Symptom-Fall
   — Wheel-Scroll speziell bei y≈399–420 (oberste Swatch-Reihe, direkt unter
   der Farbe/Schatten-Tableiste) — trat in wiederholten Tests NACH diesem Fix
   weiterhin auf (sowohl im künstlich verkleinerten #fpd-host als auch in
   einem echt auf 1300×560 verkleinerten Browserfenster). y≈460+ (Reihen 2–4)
   und HEX/Transparenz funktionierten vorher wie nachher zuverlässig. Diese
   Regel behebt also einen realen, unabhängig verifizierten CSS-Architektur-
   fehler (Phantom-Scroll-Container), löst aber NICHT nachweislich das exakte
   von Dennis gemeldete Symptom — vermutlich ein Chromium-Scroll-Hit-Testing-
   Effekt nahe der Oberkante des Scroll-Containers (angrenzend an die
   `.fpd-panel-tabs`-Leiste), nicht über die hier getesteten CSS-Mechanismen
   (overflow, overscroll-behavior, padding/margin) auflösbar. Weitere
   Untersuchung nötig (z. B. DevTools `getEventListeners()`, Test auf Dennis'
   exakter Fenstergröße, ggf. JS-seitiges Wheel-Redirect als letzte Option).
   Schatten-Tab, große Fensterhöhe (800px) und Fontliste nicht im letzten
   Testlauf erneut gegengeprüft (identischer Wrapper/Scope wie Paket 9.2,
   daher strukturell erwartbar unverändert, aber nicht extra verifiziert).
   Mobile (body > fpd-element-toolbar, eigener Block unten) durch
   #fpd-host-Scope unberührt. */
#fpd-host fpd-element-toolbar.fpd-show[data-bs-sub] .fpd-color-panel > .fpd-scroll-area {
  overflow: visible !important;
}

/* ── NUR mobile Element-Toolbar: FPD dockt sie als fixed Bottom-Sheet direkt ans
   <body> (am Desktop sitzt sie in fpd-main-bar und bleibt 100% unberührt).
   Dennis 2026-06-19: Horizontales Wischen funktionierte schlecht (zwei verschachtelte
   Scroll-Container blockierten sich) → KEIN Scrollen mehr. Stattdessen alle Werkzeuge
   FEST in kompakten Reihen, immer sichtbar; kleine Icons + kurze 1-zeilige Labels
   halten die Leiste niedrig, der Trikot-Bereich bleibt groß. ── */
body > fpd-element-toolbar .fpd-tools-nav {
  flex-direction: column !important;
  overflow: visible !important;
}
body > fpd-element-toolbar .fpd-primary-tools,
body > fpd-element-toolbar .fpd-secondary-tools {
  flex-direction: row !important;
  flex-wrap: wrap !important;
  justify-content: center;
  overflow: visible !important;
  gap: 1px 2px;
}
body > fpd-element-toolbar .fpd-primary-tools > div:not(.fpd-hidden),
body > fpd-element-toolbar .fpd-secondary-tools > div:not(.fpd-hidden) {
  flex: 0 0 auto;
  width: 54px;
  min-width: 54px;
  min-height: 48px !important;
  padding: 3px 2px 5px !important;
}
/* Icons + Labels kompakt, damit die Werkzeuge in 1-zeilige, niedrige Kacheln passen. */
body > fpd-element-toolbar .fpd-tools-nav [class*="fpd-icon-"] { font-size: 18px !important; }
body > fpd-element-toolbar .fpd-tools-nav .fpd-label {
  hyphens: manual;
  font-size: 9px !important;
  line-height: 1.1 !important;
  margin-top: 2px !important;
}
/* Schriftart-Auswahl ist ein Dropdown (kein Icon) → in der ersten Zeile neben
   Farbe/Text/Größe, schmal aber tippbar (spart eine ganze Toolbar-Zeile). */
body > fpd-element-toolbar .fpd-tool-font-family {
  width: auto !important;
  min-width: 118px !important;
  flex: 0 1 130px !important;
}

/* Alle FPD-Modals (Gespeicherte Designs, Bestätigungen etc.) */
.fpd-container .fpd-modal-dialog,
.fpd-container fpd-modal-wrapper .fpd-modal,
fpd-modal-wrapper .fpd-modal,
.fpd-modal-dialog {
  background: #ffffff !important;
  color: #1e1e1e !important;
  border: 1px solid #e5e7eb !important;
  border-radius: 12px !important;
}
.fpd-modal-dialog .fpd-modal-header,
fpd-modal-wrapper .fpd-modal-header {
  background: #f4f6f4 !important;
  color: #1e1e1e !important;
  border-bottom: 1px solid #e5e7eb !important;
}
.fpd-modal-dialog input[type="text"],
.fpd-modal-dialog input[type="email"],
fpd-modal-wrapper input[type="text"] {
  background: #ffffff !important;
  color: #1e1e1e !important;
  border: 1px solid #d1d5db !important;
  border-radius: 8px !important;
  padding: 8px 12px !important;
}

/* Default-FPD "SAVE DESIGN" etc. in Banasport-Grün */
.fpd-container button.fpd-btn.fpd-primary,
.fpd-container .fpd-btn.fpd-primary,
fpd-modal-wrapper button,
fpd-modal-wrapper .fpd-btn {
  background-color: #3f8a2f !important;
  color: #ffffff !important;
  border: none !important;
  border-radius: 8px !important;
  padding: 8px 16px !important;
  font-weight: 600 !important;
  font-size: 13px !important;
  letter-spacing: 0.03em;
}
.fpd-container button.fpd-btn.fpd-primary:hover,
.fpd-container .fpd-btn.fpd-primary:hover,
fpd-modal-wrapper button:hover {
  background-color: #4fa03a !important;
}

/* Tabs */
.fpd-container .fpd-tab.fpd-active,
.fpd-container .fpd-module-tab.fpd-active {
  color: #3f8a2f;
  border-color: #3f8a2f;
}
.fpd-container .fpd-checkbox.fpd-checked {
  background-color: #3f8a2f;
  border-color: #3f8a2f;
}

/* Guided-Tour-Button ausblenden */
.fpd-container [data-action="guided-tour"] {
  display: none !important;
}

/* Farben-Liste: Label nicht abschneiden, Toggle-Icons rechts ausreichend Platz */
.fpd-container .fpd-list-row .fpd-label,
.fpd-container fpd-module-edit-color .fpd-list-row .fpd-label {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  flex: 1 1 auto;
  min-width: 0;
}

/* Welcome-Modal beim Erstbesuch — fade + sanfter Scale-Pop */
@keyframes bs-welcome-backdrop-in {
  from { background: rgba(0, 0, 0, 0); }
  to   { background: rgba(0, 0, 0, 0.55); }
}
@keyframes bs-welcome-card-in {
  0%   { opacity: 0; transform: scale(0.85) translateY(-12px); }
  60%  { opacity: 1; transform: scale(1.02) translateY(0); }
  100% { opacity: 1; transform: scale(1) translateY(0); }
}
.bs-welcome-backdrop {
  background: rgba(0, 0, 0, 0.55);
  animation: bs-welcome-backdrop-in 0.35s ease-out;
  backdrop-filter: blur(2px);
}
.bs-welcome-card {
  animation: bs-welcome-card-in 0.55s cubic-bezier(0.16, 1, 0.3, 1);
}

/* Tour-Button im Designer-Footer: subtle Pulse-Animation, damit er nach dem
   Schließen des Welcome-Modals als "klicke mich"-Anker bleibt. Pulse läuft
   nur, solange der Cursor NICHT drauf ist — beim Hover stoppt es. */
@keyframes bs-tour-cta-pulse {
  0%, 100% { box-shadow: 0 0 0 0 rgba(63, 138, 47, 0.5); }
  50%      { box-shadow: 0 0 0 10px rgba(63, 138, 47, 0); }
}
.bs-tour-cta {
  animation: bs-tour-cta-pulse 2.4s ease-out infinite;
}
.bs-tour-cta:hover {
  animation: none;
}

/* Während der Tour (driver.js-Popover sichtbar) keinen horizontalen Scroll
   zulassen — ein Popover am rechten Rand (letzter Schritt, Anfrage-Button) ragte
   sonst raus und verschob die Seite nach links (linkes Menü unerreichbar,
   Bug-Report 2026-06-10). */
body:has(.driver-popover) {
  overflow-x: clip;
}

/* Driver.js im Banasport-Look */
.driver-popover {
  border-radius: 14px !important;
  border: 1px solid #e5e7eb !important;
  box-shadow: 0 18px 42px rgba(0,0,0,0.18) !important;
  font-family: var(--font-open-sans, system-ui), sans-serif !important;
}
.driver-popover-title {
  font-family: var(--font-kanit, system-ui), sans-serif !important;
  font-weight: 700 !important;
  color: #1e1e1e !important;
  font-size: 17px !important;
  margin-bottom: 6px !important;
}
.driver-popover-description {
  color: #4b5563 !important;
  font-size: 14px !important;
  line-height: 1.5 !important;
}
.driver-popover-footer button.driver-popover-next-btn,
.driver-popover-footer button.driver-popover-done-btn {
  background-color: #3f8a2f !important;
  color: #ffffff !important;
  border: none !important;
  padding: 8px 16px !important;
  border-radius: 8px !important;
  font-weight: 600 !important;
  text-shadow: none !important;
}
.driver-popover-footer button.driver-popover-next-btn:hover,
.driver-popover-footer button.driver-popover-done-btn:hover {
  background-color: #4fa03a !important;
}
.driver-popover-footer button.driver-popover-prev-btn {
  background-color: #f4f6f4 !important;
  color: #1e1e1e !important;
  border: 1px solid #e5e7eb !important;
  padding: 8px 14px !important;
  border-radius: 8px !important;
  text-shadow: none !important;
}
.driver-popover-progress-text {
  color: #6b7280 !important;
  font-size: 12px !important;
  font-weight: 500 !important;
}
.driver-popover-close-btn {
  color: #6b7280 !important;
}
.driver-popover-close-btn:hover {
  color: #1e1e1e !important;
}

/* Position-Panel: "Ausrichten"-Tab ausblenden — die Buttons (Top/Middle/Bottom
   etc.) richten am Canvas aus, nicht am Trikot, was für unsere Use-Case
   irreführend ist. "Reihenfolge"/Arrange (Move Up/Down) bleibt der einzige
   sichtbare Inhalt; Tab-Header verstecken wir auch, da nur ein Tab übrig. */
fpd-element-toolbar .fpd-panel-position .fpd-panel-tabs [data-tab="align"],
fpd-element-toolbar .fpd-panel-position .fpd-panel-tabs-content [data-id="align"] {
  display: none !important;
}
fpd-element-toolbar .fpd-panel-position .fpd-panel-tabs {
  display: none !important;
}
fpd-element-toolbar .fpd-panel-position .fpd-panel-tabs-content [data-id="arrange"] {
  display: block !important;
}

/* Export-Modal (JPG/PNG/PDF/SVG) — Icons + Toggle im Light-Look */
.fpd-container .fpd-download-dialog,
fpd-modal-wrapper .fpd-download-dialog {
  background: #ffffff !important;
  color: #1e1e1e !important;
}
.fpd-container .fpd-download-dialog .fpd-btn-group > *,
fpd-modal-wrapper .fpd-download-dialog .fpd-btn-group > * {
  border: 1px solid #d1d5db !important;
  color: #1e1e1e !important;
  background: #ffffff !important;
}
.fpd-container .fpd-download-dialog .fpd-btn-group > *:hover,
fpd-modal-wrapper .fpd-download-dialog .fpd-btn-group > *:hover {
  border-color: #3f8a2f !important;
  color: #3f8a2f !important;
  background: rgba(63, 138, 47, 0.05) !important;
}

/* Nur "Umrandung" (stroke) im Color-Panel ausblenden — der "Schatten"-Tab ist
   auf Dennis-Wunsch (2026-06-16) für Schriften & Logos wieder aktiv. (Schatten
   war zuvor mit ausgeblendet, weil er einen freien RGB-Kreis mitbringt; der
   Kunde möchte den Schatten jetzt aber nutzen.) */
.fpd-container .fpd-panel-color .fpd-panel-tabs span[data-tab="stroke"],
fpd-element-toolbar .fpd-panel-color .fpd-panel-tabs span[data-tab="stroke"],
fpd-element-toolbar .fpd-panel-tabs span[data-tab="stroke"] {
  display: none !important;
}

/* Produkte-Picker als saubere Kacheln (Wunsch Dennis 2026-05-31, neu gebaut
   2026-06-01 weil Bild und Name sich überlappten):
   - jedes Produkt eine eigene Karte mit Rahmen + Hover
   - drei getrennte Zonen die sich NIE überlappen können:
       Badge (absolut oben links) · Trikot · Set-Name
   Schlüssel: Die Kachel ist ein FLEX-COLUMN. FPD rendert pro Item nur ein leeres
   <picture> (Background-Bild, kein <img>-Kind) und legt den Titel im
   `data-title`-Attribut ab. Im FPD-Default-Flex kollabiert dieses leere <picture>
   im Layout-Flow (trägt 0 zur Kachelhöhe bei) → ein absolut gesetzter Titel
   landete mitten im Bild. Lösung: <picture> als nicht-schrumpfbares Flex-Item mit
   fester Höhe, und den Titel als ECHTES Flow-Element (::after als letztes
   Flex-Child, NICHT absolut). So sitzen Bild oben und Name darunter, getrennt. */
fpd-module-products .fpd-grid {
  display: grid !important;
  grid-template-columns: repeat(2, 1fr) !important;
  /* FPD-Default ist grid-auto-rows:100px (aus .fpd-container .fpd-grid) — die
     196px-Karten ragten dadurch aus ihrer 100px-Zeile und überlappten die
     nächste Reihe. `auto` lässt jede Zeile auf Kartenhöhe wachsen. */
  grid-auto-rows: auto !important;
  align-items: start !important;
  gap: 8px !important;
  padding: 4px !important;
}
fpd-module-products .fpd-grid .fpd-item {
  position: relative;
  display: flex !important;
  flex-direction: column !important;
  align-items: stretch !important;
  justify-content: flex-start !important;
  height: auto !important;
  /* kompakt für 27"-Arbeit (Dennis 2026-06-01) — weniger Scrollen */
  min-height: 124px !important;
  margin: 0 !important;
  /* oben 21px Platz fürs (kleinere) Badge, sodass das Trikot nicht darunter liegt */
  padding: 21px 6px 7px !important;
  background: #ffffff !important;
  border: 1px solid #e5e7eb !important;
  border-radius: 10px !important;
  box-shadow: 0 1px 2px rgba(0, 0, 0, 0.04) !important;
  transition: border-color 0.15s ease, box-shadow 0.15s ease, transform 0.15s ease;
  overflow: hidden;
}
fpd-module-products .fpd-grid .fpd-item:hover {
  border-color: #3f8a2f !important;
  box-shadow: 0 6px 16px rgba(63, 138, 47, 0.14) !important;
  transform: translateY(-2px);
}
fpd-module-products .fpd-grid .fpd-item.fpd-active {
  border-color: #3f8a2f !important;
  box-shadow: 0 0 0 2px rgba(63, 138, 47, 0.35) !important;
}
/* Trikot-Zone: festes, nicht-schrumpfbares Flex-Item.
   WICHTIG: Die Vorschau ist ein <picture> mit inline background-image —
   NICHT `background` überschreiben (sonst verschwindet das Trikot!). */
fpd-module-products .fpd-grid .fpd-item > picture {
  display: block !important;
  flex: 0 0 76px !important;
  height: 76px !important;
  min-height: 76px !important;
  width: 100% !important;
  background-size: contain !important;
  background-repeat: no-repeat !important;
  background-position: center !important;
  border: none !important;
}
/* Set-Name-Zone: echtes Flow-Element (Flex-Child) unter dem Bild — keine
   absolute Position, kann das Trikot also nicht überlappen. */
fpd-module-products .fpd-grid .fpd-item::after {
  content: attr(data-title);
  flex: 0 0 auto;
  margin-top: 6px;
  font-size: 11px;
  line-height: 1.2;
  font-weight: 600;
  text-align: center;
  color: var(--fpd-text-color, #1e1e1e);
  white-space: normal;
  overflow: hidden;
  text-overflow: clip;
  text-transform: none;
  border: none !important;
}

/* Standard/Premium-Badge oben links auf jeder Produkt-Kachel. Das Tier wird
   per JS (aus set-config.json) als data-tier auf die .fpd-item gesetzt. */
fpd-module-products .fpd-grid .fpd-item[data-tier]::before {
  content: attr(data-tier);
  position: absolute;
  top: 5px;
  left: 5px;
  z-index: 2;
  font-size: 8px;
  font-weight: 700;
  text-transform: uppercase;
  letter-spacing: 0.03em;
  line-height: 1;
  padding: 2px 5px;
  border-radius: 5px;
  color: #ffffff;
  pointer-events: none;
}
fpd-module-products .fpd-grid .fpd-item[data-tier="Premium"]::before {
  background: #3f8a2f;
}
fpd-module-products .fpd-grid .fpd-item[data-tier="Standard"]::before {
  background: #9ca3af;
}

/* QR-Code-Funktion im Bilder-Modul ausblenden — Banasport bietet nur
   Bild-Upload an, keinen QR-Code (Wunsch Dennis 2026-05-31). FPD rendert QR
   als eigenes Sub-Panel (fpd-module-qr-code) mit Tab-Button (Icon
   fpd-icon-qrcode) innerhalb der Modul-Tab-Leiste. */
.fpd-container fpd-module-qr-code,
.fpd-container .fpd-module-qr-code,
fpd-module-qr-code,
.fpd-container fpd-module-tabs > div:has(.fpd-icon-qrcode),
.fpd-container .fpd-module-tabs > div:has(.fpd-icon-qrcode),
.fpd-container .fpd-module-tabs-list > *:has(.fpd-icon-qrcode) {
  display: none !important;
}

/* ============================================================
   MOBILE / TABLET-PORTRAIT  (≤ 1023px)
   ------------------------------------------------------------
   Das Desktop-Layout oben zwingt #fpd-host in ein 2-Spalten-Grid mit fester
   400px-Sidebar. Auf schmalen Viewports passt allein die Sidebar nicht aufs
   Display → die Trikot-Stage bekommt 0px Breite und ist unsichtbar.
   FPD selbst erkennt schmale Container und setzt die Klasse `fpd-layout-small`
   (Nav-Icons werden dann horizontal). Wir lösen daher das Grid auf und stapeln
   vertikal in der für Mobil sinnvollen Reihenfolge:
       Werkzeug-Leiste (Topbar) → Trikot-Stage groß → Module unten.
   ============================================================ */
@media (max-width: 1023px) {
  /* Grid-Override aufheben → vertikaler Flex-Stapel, volle Breite */
  #fpd-host.fpd-banasport.fpd-sidebar {
    display: flex !important;
    flex-direction: column !important;
    /* FPDs CSS setzt auf dem Container flex-wrap:wrap. In einer flex-COLUMN mit
       einem wachsenden Item (main-bar: flex 1 1 auto) erzeugt das eine große
       leere Lücke zwischen Stage und Werkzeug-Bar (~300px!). nowrap erzwingen
       → die drei Bereiche stapeln dicht. (Ursache des „zu viel Luft", 06-10.) */
    flex-wrap: nowrap !important;
    grid-template-columns: none !important;
    grid-template-rows: none !important;
    grid-template-areas: none !important;
    --fpd-sidebar-width: 100%;
    /* WICHTIG: --fpd-sidebar-nav-width NICHT auf 100% setzen! FPDs CSS nutzt
       diese Variable in fpd-layout-small als `margin-bottom` der Stage
       (`fpd-main-wrapper { margin-bottom: var(--fpd-sidebar-nav-width) }`).
       100% bezieht sich auf die BREITE (~354px) → riesige Lücke zwischen Trikot
       und Werkzeug-Bar. War die Ursache des „zu viel Luft" (06-10). */
    min-height: auto !important;
    height: auto !important;
  }

  /* Reihenfolge: Topbar (0) → Stage (1) → Modul-Bar (2). Alle volle Breite,
     grid-area zurücksetzen (sonst gewinnt die Desktop-Zuweisung). */
  #fpd-host.fpd-banasport.fpd-sidebar > fpd-actions-bar {
    grid-area: auto !important;
    order: 0;
    width: 100% !important;
    flex: 0 0 auto;
  }
  #fpd-host.fpd-banasport.fpd-sidebar > fpd-main-wrapper {
    grid-area: auto !important;
    order: 1;
    width: 100% !important;
    min-width: 0 !important;
    flex: 0 0 auto;
    /* Höhe an FPDs Canvas-Seitenverhältnis (stageWidth 1000 : stageHeight 720)
       koppeln statt fester vh — so sitzt das Trikot bündig ohne den großen
       grauen Leerraum, der vorher unnötiges Scrollen erzeugte. */
    height: auto !important;
    aspect-ratio: 1000 / 720;
    min-height: 240px !important;
    max-height: 62vh;
    /* FPD setzt in fpd-layout-small margin-bottom:var(--fpd-sidebar-nav-width)
       auf die Stage → hart auf 0, damit die Werkzeug-Bar direkt anschließt. */
    margin-bottom: 0 !important;
  }
  /* FPD setzt die main-bar im Mobile-Modus per JS auf position:absolute mit
     z-index:2147483647 (Overlay über ALLES, inkl. Site-Header/Modals) und
     verdeckt damit das Trikot. Wir holen sie zurück in den normalen Fluss,
     direkt unter die Stage, und zähmen den z-index. */
  #fpd-host.fpd-banasport.fpd-sidebar > fpd-main-bar {
    grid-area: auto !important;
    order: 2;
    position: static !important;
    z-index: auto !important;
    top: auto !important;
    left: auto !important;
    width: 100% !important;
    height: auto !important;
    max-height: none !important;
    flex: 1 1 auto;
    display: flex !important;
    flex-direction: column !important;
    border-right: none !important;
    border-top: 1px solid #e5e7eb !important;
    background: #ffffff !important;
  }

  /* Stage füllt die volle Breite des Wrappers */
  #fpd-host.fpd-banasport.fpd-sidebar .fpd-product-stage {
    width: 100% !important;
    height: 100% !important;
  }

  /* Reihenfolge innerhalb der Modul-Bar: Werkzeug-Tabs (Nav) zuerst, direkt
     unter dem Trikot — dann der Modul-Inhalt darunter. FPD nutzt intern
     order (Nav order:2, Content order:0); wir kehren das um. Die Nav wird
     dabei zur horizontalen Tab-Leiste — FPD stapelt sie auf Tablet sonst
     vertikal (nimmt ~470px). */
  #fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-navigation {
    order: 0 !important;
    width: 100% !important;
    flex: 0 0 auto;
    /* display:flex erzwingen — FPD nutzt im Tablet-Modus (fpd-layout-medium)
       display:block, dann hätte flex-direction keinen Effekt. */
    display: flex !important;
    flex-direction: row !important;
    flex-wrap: nowrap !important;
    justify-content: space-between !important;
    align-items: stretch !important;
    gap: 2px;
    border-bottom: 1px solid #e5e7eb;
    background: #ffffff !important;
    padding: 4px 4px 0 !important;
    overflow-x: auto;
  }
  #fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-navigation .fpd-nav-item {
    flex: 1 1 0 !important;
    flex-direction: column !important;
    gap: 4px !important;
    margin: 0 !important;
    padding: 9px 4px !important;
    min-width: 0 !important;
    min-height: 56px;
    text-align: center;
    border-radius: 10px 10px 0 0 !important;
    /* aktiver Tab: grüne Unterstreichung als klare Tab-Metapher */
    border-bottom: 2px solid transparent !important;
  }
  #fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-navigation .fpd-nav-item .fpd-label {
    font-size: 11px !important;
    line-height: 1.1 !important;
    white-space: nowrap;
  }
  #fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-navigation .fpd-nav-item.fpd-active {
    background: rgba(63, 138, 47, 0.08) !important;
    border-bottom-color: #3f8a2f !important;
  }
  #fpd-host.fpd-banasport.fpd-sidebar fpd-main-bar > .fpd-module-content {
    order: 1 !important;
    display: block !important;
    position: static !important;
    width: 100% !important;
    height: auto !important;
    min-height: 300px;
    background: #ffffff !important;
  }

  /* Zoom/Pan-Bedienfeld (öffnet über den Zoom-Button) auf Touch größer +
     deutlicher. Das Hand-Icon (fpd-icon-drag) schaltet den Verschiebe-Modus
     ein, damit man das gezoomte Trikot mit dem Finger pannen kann
     (Dennis-Feedback „nur Mitte zoomen, kann nicht verschieben", 06-10). */
  .fpd-zoom-wrapper {
    transform: scale(1.25);
    transform-origin: center;
    box-shadow: 0 6px 20px rgba(0,0,0,0.18) !important;
  }
  .fpd-zoom-wrapper > span {
    min-width: 32px;
    min-height: 32px;
    display: inline-flex !important;
    align-items: center;
    justify-content: center;
    font-size: 20px !important;
  }
}

/* ─── Designer-Interaktion: aktive Farbe, HEX-Eingabe, Pan (2026-06-11) ─────
   Gilt für ALLE Viewports (nicht im mobile-@media), greift in die von FPD
   gerenderte Element-Toolbar ein. Die Klassen werden von FPDDesigner.tsx
   (MutationObserver-Augmentierung) gesetzt bzw. injiziert. */

/* 2) Aktive Farb-Swatch: deutlicher Ring + Häkchen auf der Swatch, die der
      aktuell gewählten Element-Farbe entspricht. */
.fpd-color-palette .fpd-item.bs-swatch-active {
  position: relative;
  outline: 3px solid #3f8a2f !important;
  outline-offset: 1px;
  box-shadow: 0 0 0 1px #fff inset, 0 0 6px rgba(63,138,47,0.6) !important;
  transform: scale(1.12);
  z-index: 2;
}
.fpd-color-palette .fpd-item.bs-swatch-active::after {
  content: "";
  position: absolute;
  left: 50%;
  top: 48%;
  width: 5px;
  height: 9px;
  border: solid #fff;
  border-width: 0 2px 2px 0;
  transform: translate(-50%, -55%) rotate(45deg);
  filter: drop-shadow(0 0 1px rgba(0,0,0,0.7));
  pointer-events: none;
}

/* 3) HEX-Eingabefeld unter der Farbpalette (für Vereins-/Logo-Farben).
   Höhere Spezifität + !important, weil FPDs globale Input-/Wrapper-Styles
   (.fpd-color-wrapper) die Höhe sonst auf ~80px aufblähen (Screenshot 06-11). */
.fpd-banasport .bs-hex-row {
  display: flex !important;
  align-items: center !important;
  gap: 8px;
  margin: 12px 8px 6px;
  padding-top: 12px;
  border-top: 1px solid rgba(0,0,0,0.08);
  box-sizing: border-box;
}
.fpd-banasport .bs-hex-label {
  flex: 0 0 auto;
  font-size: 12px;
  font-weight: 700;
  letter-spacing: 0.04em;
  color: #6b7280;
}
.fpd-banasport .bs-hex-input {
  flex: 1 1 auto;
  /* Paket 3 (Dennis 2026-07-02, Befund 2): min-width:0 ließ das Input im schmalen
     Sub-Panel auf ~58px schrumpfen → „#1A2…" statt „#1A2B3C" (voller Wert braucht
     gemessen 83px: 15px-Monospace + 2×10px padding + Border). 88px = Placeholder
     komplett sichtbar; im 238px-Sub-Panel bleibt die Zeile HEX|Input|OK einzeilig
     (25+8+88+8+52 = 181px ≤ 202px Zeilenbreite). */
  min-width: 88px;
  width: auto !important;
  height: 40px !important;
  min-height: 40px !important;
  max-height: 40px !important;
  margin: 0 !important;
  padding: 0 10px !important;
  border: 1px solid #d1d5db !important;
  border-radius: 8px !important;
  font-size: 15px !important;
  line-height: 38px !important;
  font-family: ui-monospace, SFMono-Regular, Menlo, monospace;
  text-transform: uppercase;
  color: #111827;
  background: #fff !important;
  box-sizing: border-box !important;
}
.fpd-banasport .bs-hex-input:focus {
  outline: none;
  border-color: #3f8a2f !important;
  box-shadow: 0 0 0 2px rgba(63,138,47,0.18) !important;
}
.fpd-banasport .bs-hex-input.bs-hex-invalid {
  border-color: #c6000f !important;
  box-shadow: 0 0 0 2px rgba(198,0,15,0.18) !important;
}
.fpd-banasport .bs-hex-apply {
  flex: 0 0 auto;
  height: 40px !important;
  min-width: 52px;
  padding: 0 16px !important;
  border: none !important;
  border-radius: 8px !important;
  background: #3f8a2f !important;
  color: #fff !important;
  font-size: 14px !important;
  font-weight: 700 !important;
  line-height: 40px !important;
  white-space: nowrap;
  cursor: pointer;
  box-sizing: border-box !important;
}
.fpd-banasport .bs-hex-apply:hover { background: #2a6f1a !important; }

/* 4) Pan-Toggle („Hand") deutlich sichtbar, aktiver Zustand grün. So erkennt
      der Kunde, dass er nach dem Zoomen den Ausschnitt verschieben kann. */
.fpd-stage-pan {
  cursor: grab;
  border-radius: 8px;
  transition: background 0.15s, color 0.15s;
}
.fpd-stage-pan.fpd-active,
.fpd-stage-pan.fpd-toggle-active {
  background: #3f8a2f !important;
  color: #fff !important;
}
.fpd-stage-pan.fpd-active .fpd-icon-drag,
.fpd-stage-pan.fpd-toggle-active .fpd-icon-drag {
  color: #fff !important;
}

/* ─── Feedback 2026-06-12 ──────────────────────────────────────────────── */

/* Farbpalette NICHT scrollen, wenn genug Platz ist: FPD setzt der Scroll-Area
   um die Palette ein max-height:100px → die 4. Farbreihe war abgeschnitten.
   Ab Tablet/Desktop (genug Platz) alle Reihen zeigen (Dennis 06-12). */
@media (min-width: 768px) {
  fpd-element-toolbar .fpd-panel-color .fpd-scroll-area,
  fpd-element-toolbar .fpd-color-panel .fpd-scroll-area {
    max-height: none !important;
    overflow-y: visible !important;
  }
}

/* QA 2026-07-02 (Farbpalette): Die OBERSTE Swatch-Reihe war oben angeschnitten.
   Ursache: FPD setzt auf .fpd-scroll-area „padding:0 !important"; der Auswahl-
   Ring der aktiven Swatch (outline 3px + offset 1px + scale 1.12, siehe
   .bs-swatch-active) ragt ~5px über die erste Reihe hinaus und wurde vom
   Scroll-/Clip-Container gekappt (overflow-x:hidden macht overflow-y trotz
   „visible" effektiv zu „auto"). padding-top schafft die nötige Luft — gilt
   für alle Viewports; !important + höhere Spezifität überstimmt FPDs padding:0. */
fpd-element-toolbar .fpd-panel-color .fpd-scroll-area,
fpd-element-toolbar .fpd-color-palette > .fpd-scroll-area {
  padding-top: 8px !important;
}

/* Paket 3 (Dennis 2026-07-02, Befund 1): Gleiches Problem SEITLICH — der Ring der
   ersten Swatch einer Reihe (Spalte links) wurde an der linken Kante gekappt.
   Clipper ist die INNERE .fpd-scroll-area (direkter Wrapper der Palette, overflow:auto,
   DOM-verifiziert: Swatch x=238 == Container x=238 → Ring ragt ~5,4px darüber hinaus:
   outline 3px + offset 1px + scale 1.12 ≈ +1,4px). 8px Luft links UND rechts; die
   Palette (flex-wrap) verteilt die Swatches im Rest von selbst neu — mit dem breiteren
   Sub-Panel (s. width:100% auf fpd-main-bar) bleiben es ≥5 Spalten (gemessen: 6). */
fpd-element-toolbar .fpd-color-wrapper .fpd-scroll-area {
  padding-inline: 8px !important;
}

/* Paket 4 (Dennis 2026-07-02, Punkt B): GLEICHES Ring-Clipping oben, aber in einem
   ANDEREN Container — dem MODUL „Farben" (fpd-module-manage-layers), nicht der
   Element-Werkzeugleiste. Dort hat jede aufgeklappte Layer-Zeile (z.B. „Banasport")
   ihre EIGENE Palette in `.fpd-color-panel.fpd-cell-full` (overflow:hidden,
   padding-top:0 von FPD) — DOM-verifiziert: Swatch-Top 338.26 vs. Container-Top 339.70
   → der Ring der obersten (selektierten) Swatch-Reihe ragt ~5-6px darüber hinaus und
   wird gekappt. Seitlich (links) bereits 8,6px Luft vorhanden, daher hier NUR padding-top.
   Scoped auf fpd-module-manage-layers, damit die Element-Werkzeugleisten-Regeln oben
   unberührt bleiben (getrennte DOM-Bäume, unterschiedliche FPD-Module). */
fpd-module-manage-layers .fpd-color-panel.fpd-cell-full {
  padding-top: 8px !important;
}

/* „Zur Mitte"-Tool am ENDE der Element-Werkzeugliste (nur Text/Logo). */
fpd-element-toolbar .bs-tool-center { cursor: pointer; }
fpd-element-toolbar .bs-tool-center .bs-center-icon {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  font-size: 18px;
  line-height: 1;
}
fpd-element-toolbar .bs-tool-center:hover { color: #3f8a2f; }

/* SCROLL-FIX (Dennis 2026-06-16 „scroll ging nicht dahin"): die vertikale
   Werkzeugliste lief unten knapp über den sichtbaren Bereich → das letzte Tool
   (Entfernen / Zur Mitte) war nicht erreichbar. Genug Platz am Ende der
   scrollbaren Nav, damit bis ganz unten gescrollt werden kann. */
fpd-element-toolbar .fpd-tools-nav { padding-bottom: 56px !important; }

/* Standardfarben-Hinweis direkt unter der (kleinen) Standardfarben-Palette
   im Farb-Panel (Dennis 2026-06-15/16). Im Element-Toolbar-Flow, bricht NICHT
   das Layer-Modul. */
.bs-stdcolor-note {
  margin: 10px 6px 2px;
  padding-top: 8px;
  border-top: 1px solid rgba(0,0,0,0.08);
  color: #6b7280;
  font-size: 11.5px;
  line-height: 1.4;
}

/* „Angemeldet"-Hinweis NATIV in der Menü-Leiste (Actions-Bar, dunkel) — wie ein
   eigenes Bar-Element (User-Icon + Text), heller Text, dezenter Hintergrund;
   gut lesbar, gehört optisch zum System (Dennis 2026-06-18). */
/* Sauberes Leisten-Segment statt schwebendem Kasten: volle Bar-Höhe, dezente
   Trennlinie zu „Menü", transparent — wirkt wie ein nativer Bar-Bereich. */
.bs-login-badge {
  display: inline-flex;
  align-items: center;
  align-self: stretch;
  /* FPD gibt jedem direkten Bar-Segment `flex:1; max-width:33%` → ohne diese
     Overrides würde das Badge ein volles 330px-Segment und von space-between
     mittig geschoben. Schmal halten + margin-right:auto schiebt die übrigen
     Segmente (Rückgängig/Zoom) nach rechts → Badge sitzt links neben „Menü". */
  flex: 0 0 auto !important;
  max-width: none !important;
  margin-right: auto !important;
  gap: 8px;
  padding: 0 16px;
  border-left: 1px solid rgba(255, 255, 255, 0.16);
  background: transparent;
  color: rgba(255, 255, 255, 0.9) !important;
  font-size: 13px;
  font-weight: 500;
  white-space: nowrap;
}
.bs-login-badge svg { flex: 0 0 auto; opacity: 0.85; }
@media (max-width: 900px) {
  .bs-login-badge { display: none; } /* auf schmalen Leisten ausblenden, Platz sparen */
}

/* Das erste Actions-Menü (Herunterladen/Drucken/Zurücksetzen/Vorschau) IMMER als
   aufklappbares „Menü"-Dropdown lassen, nie offen in der Leiste ausgebreitet
   (Dennis 2026-06-20) → die Leiste bleibt schmal, der „Angemeldet"-Badge hat Platz
   und die Buttons überlappen nicht mehr. */
fpd-actions-bar > div:first-child fpd-actions-menu > .fpd-uncollapsed-menu {
  display: none !important;
}
fpd-actions-bar > div:first-child fpd-actions-menu > .fpd-collapsed-menu {
  display: flex !important;
  /* FPD hängt im uncollapsed-Modus (breiter Screen) `fpd-hidden` ans collapsed-
     Menü → das setzt NEBEN display:none auch `pointer-events:none !important`.
     Wir überschreiben display, müssen aber pointer-events explizit zurückholen,
     sonst ist der „☰ Menü"-Button sichtbar, aber tot. */
  pointer-events: auto !important;
  /* collapsed/uncollapsed sind FPD-seitig `position:absolute` → das Menü-Segment
     kollabiert dann auf Breite 0 (Badge überlappt den Button). Im Flow (static)
     bekommt der „Menü"-Button echte Breite, das Badge sitzt sauber daneben. */
  position: static !important;
}
/* Erstes Bar-Segment (das „Menü"-Dropdown) nur so breit wie der Button — sonst
   nähme es als flex:1-Segment ~1/4 der Leiste ein und schöbe das Badge nach rechts. */
fpd-actions-bar > div:first-child {
  flex: 0 0 auto !important;
  max-width: none !important;
}

/* Set-Wechsel: Element-Toolbar (Farbwähler) kurzzeitig ausblenden, während FPD die
   Custom-Elemente re-addet und dabei wiederholt automatisch selektiert. Ohne das
   flackerte die Toolbar zwischen Auf/Zu (Dennis 2026-06-23). Wird per JS-Klasse
   `bs-set-switching` für ~1,8 s nach dem Set-Klick gesetzt und bei einem echten
   Canvas-Klick sofort wieder entfernt. */
body.bs-set-switching fpd-element-toolbar { display: none !important; }

/* ─── Bearbeiten-Menü aufräumen (Dennis 2026-06-28) ──────────────────────── */

/* Punkt 1 — HANDY-Bottom-Sheet: das 56px-padding-bottom (Zeile ~945, eigentlich
   nur für die scrollbare Tablet-/Desktop-Liste gedacht, damit das letzte Tool
   erreichbar bleibt) erzeugt auf dem Handy nur verschwendeten Leerraum unter den
   Werkzeug-Reihen, weil dort nichts scrollt. Auf dem Bottom-Sheet wieder schließen. */
body > fpd-element-toolbar .fpd-tools-nav { padding-bottom: 8px !important; }

/* Punkt 2 — die scrollbare VERTIKALE Werkzeugliste (docked, in #fpd-host). */
/* 2.3 „Balken liegt blöd über dem Inhalt": eigene, dünne Scrollbar + scrollbar-gutter
   reserviert die Spur rechts, sodass sie nicht mehr über die Tools liegt. */
#fpd-host fpd-element-toolbar .fpd-tools-nav {
  /* per JS (capNavHeight) auf Fensterhöhe gekappt → hier scrollen, damit eine
     sichtbare Unterkante mit Scroll-Schatten entsteht. */
  overflow-y: auto;
  /* Paket 3 (Dennis 2026-07-02, Befund 4): „Zittern" der Werkzeugleiste. Ursache
     (DOM-belegt, z.B. 1280×650): OHNE eigenes max-height streckt Flex die Nav auf
     Toolbar-Höhe (z.B. 384px) → scrollHeight ≥ clientHeight (384) > avail+4 (379)
     → capNavHeight (FPDDesigner.tsx) setzt inline maxHeight=avail (375) → damit
     scrollHeight=Inhalt (378) ≤ 379 → Cap wird wieder ENTFERNT → Streckung → …
     Der style-Write triggert jedes Mal den MutationObserver → Endlos-Flip mit
     ~10px Höhensprung pro Frame = das Zittern. Fix: dieselbe Kappung (12px Luft
     zur Designer-Unterkante) FEST in CSS — die Nav ist damit nie höher als
     capNavHeights avail, dessen Bedingung bleibt dauerhaft falsch → kein
     inline-Write mehr, ein einziger stabiler Zustand (Scroll-Schatten bleibt). */
  max-height: calc(100% - 12px);
  scrollbar-gutter: stable;
  scrollbar-width: thin;                       /* Firefox */
  scrollbar-color: #b9bec5 transparent;
  /* 2.1 „man erkennt nicht, dass da mehr ist": Scroll-Shadow-Technik (Lea Verou).
     Zwei weiße Cover-Layer (background-attachment:local → scrollen MIT dem Inhalt) und
     zwei Schatten-Layer (attachment:scroll → kleben am Container-Rand). Am Anfang deckt
     das obere Cover den oberen Schatten zu; sobald mehr Inhalt unten ist, erscheint
     UNTEN ein deutlicher Schatten („es geht weiter"), der am Listenende von selbst
     verschwindet. Rein CSS, erkennt Scrollbarkeit automatisch. */
  background-color: #ffffff;
  background-image:
    linear-gradient(#ffffff 30%, rgba(255, 255, 255, 0)),
    linear-gradient(rgba(255, 255, 255, 0), #ffffff 70%),
    radial-gradient(farthest-side at 50% 0, rgba(0, 0, 0, 0.28), rgba(0, 0, 0, 0)),
    radial-gradient(farthest-side at 50% 100%, rgba(0, 0, 0, 0.28), rgba(0, 0, 0, 0));
  background-position: 0 0, 0 100%, 0 0, 0 100%;
  background-repeat: no-repeat;
  background-size: 100% 26px, 100% 26px, 100% 16px, 100% 16px;
  background-attachment: local, local, scroll, scroll;
}
#fpd-host fpd-element-toolbar .fpd-tools-nav::-webkit-scrollbar { width: 6px; }
#fpd-host fpd-element-toolbar .fpd-tools-nav::-webkit-scrollbar-track { background: transparent; }
#fpd-host fpd-element-toolbar .fpd-tools-nav::-webkit-scrollbar-thumb {
  background: #b9bec5;
  border-radius: 3px;
}
#fpd-host fpd-element-toolbar .fpd-tools-nav::-webkit-scrollbar-thumb:hover { background: #9aa0a8; }
/* 2.2 „Abstände viel zu groß": Icon/Label/Gap im docked Nav verkleinern, damit auch
   die Tools mit 2-zeiligem Label (z.B. „Text bearbeiten") niedrig bleiben (~54px statt
   68px) → mehr Werkzeuge gleichzeitig sichtbar. */
#fpd-host fpd-element-toolbar .fpd-tools-nav [class*="fpd-icon-"] { font-size: 20px !important; }
#fpd-host fpd-element-toolbar .fpd-tools-nav .fpd-label {
  /* QA 2026-07-02: Kleinschrift-Workaround (8,5px) zurückgenommen — im
     2-Spalten-Grid (s.o.) ist die Spalte breit genug für die normale
     Skin-/FPD-Standardgröße der Tool-Labels (11px). */
  font-size: 11px !important;
  line-height: 1.2 !important;
  margin-top: 2px !important;
}

/* ─── Punkt D (Dennis 2026-07-02): Schriftarten-Liste vergrößern ─────────────
   Root Cause DOM-verifiziert: FPDs EIGENES Basis-CSS deckelt die Liste hart auf
   `.fpd-sub-panel .fpd-panel-font-family .fpd-fonts-list{max-height:100px}` —
   UNABHÄNGIG davon, wie viel Platz das Sub-Panel tatsächlich hat (gemessen im
   Live-Designer: Sub-Panel ~496px hoch, Scroll-Area ~414px verfügbar, aber die
   Liste durfte nur 100px nutzen → nur 2-3 Schriften sichtbar, Rest zwingend
   Scroll). Zusätzlich addiert FPDs `gap:20px` zwischen den Einträgen unnötig
   viel Leerraum. Fix: den harten 100px-Deckel aufheben (volle Sub-Panel-Höhe
   nutzen, die bereits korrekt an die Designer-Höhe gekoppelt ist — siehe
   #fpd-host-Höhenkette weiter oben) und den Zeilenabstand verdichten. Docked
   (Desktop) UND mobiles Bottom-Sheet (body > fpd-element-toolbar) sind BEIDE
   von derselben FPD-Basisregel betroffen, daher hier ungescoped (kein #fpd-host-
   Präfix) — wirkt also für beide Layouts. Andere Sub-Panels (Farbe, Größe etc.)
   nutzen `.fpd-fonts-list` nicht → keine Seiteneffekte. */
.fpd-sub-panel .fpd-panel-font-family .fpd-fonts-list {
  max-height: 100% !important;
  gap: 6px !important;
}
/* Mobil (Bottom-Sheet, an <body> gedockt): FPD begrenzt dort die gesamte Sub-
   Panel-Höhe zusätzlich enger als am Desktop. Fürs Schriftart-Panel gezielt mehr
   vom verfügbaren Viewport freigeben, ohne die anderen Bottom-Sheet-Panels (Farbe,
   Format …) zu vergrößern — sonst würde z.B. die Farbpalette unnötig hoch und
   drückt das Trikot aus dem sichtbaren Bereich. */
@media (max-width: 1023px) {
  body > fpd-element-toolbar .fpd-sub-panel:has(.fpd-panel-font-family.fpd-active) {
    max-height: 60vh !important;
  }
  body > fpd-element-toolbar .fpd-panel-font-family.fpd-active {
    max-height: none !important;
  }
}

/* ─── Punkt #11 (Dennis 2026-07-06): Schriftart-Suchleiste entfernen ──────────
   Das Font-Panel hat oben ein direktes <input type="text"> (FPD-Standard,
   placeholder "Search Fonts") als Filter. Dennis will es weg. Die Font-Liste
   bleibt voll funktionsfähig (die Suche ist nur ein optionales Filter-Feature).
   Selektor bewusst auf das DIREKTE input-Kind des Font-Panels gescoped — trifft
   NICHT die Such-/Filterfelder der Bilder-/Designs-Grids (die haben eigene
   Klassen, .fpd-input-search). !important, da FPDs Vendor-CSS nach fpd-brand.css
   lädt. Ungescoped (kein #fpd-host) → wirkt für Desktop-Dock UND Mobile-Sheet. */
.fpd-panel-font-family > input[type="text"] {
  display: none !important;
}