:root { /* Gemeinsame Basis für .item-sub und Buttons (Nutzeranfrage 21.08.2026). Nach mehreren Anpassungsrunden (Nutzeranfrage 21.08.2026) liegen Buttons wieder auf demselben Wert wie .item-sub. .found-btn (Mitarbeiter einstellen/Wartung/Experten/Auto-Verkauf/ Firma abreißen/Speichern) zieht auf denselben Button-Wert gleich (Nutzeranfrage 21.08.2026), statt eigener fester 12px. */ --text-size-normal: calc(12px + 2pt); --text-size-button: var(--text-size-normal); /* Feste Breite für Graph + Kurszeile in Waren-/Aktienmarkt-Karten (.sparkline-wrap, .price-tag.price-split, .order-toggle-btn-slot, siehe styles.css weiter unten) sowie das Farbschema - als eine einzige Variable statt drei unabhängiger 250px/400px-Werte, seit sich diese Breite bereits mehrfach geändert hat (26.08.2026) und alle drei Stellen synchron bleiben müssen, damit Preiszeile/Button weiterhin exakt unter dem Graph sitzen. Nutzeranfrage 26.08.2026 ("Bereich muss breiter sein, sodass der gesamte Text auch bei einem Kurs von 100.000.000 MC in einer Zeile passt"): 400px, live gemessen für "Verkauf 100.000.000,00 MC" (≈175px) + "Kauf 100.000.000,00 MC" (≈156px, beide 1fr-Spalten des Preis-Grids gleich breit wie die längere) + Dreieck + Spaltenabstände - ausdrücklich Platzhalter mit Puffer, keine pixelgenaue Untergrenze. Nachtrag (26.08.2026, Nutzeranfrage "bei zwei Dritteln Fensterbreite sieht es teilweise nicht gut aus" - Ursache: der feste 400px-Wert blieb bis exakt 820px unverändert und sprang dort abrupt auf 100%, wodurch .market-right (Kaufen/Verkaufen-Buttons) im Bereich ca. 820-1050px Fensterbreite keinen Platz mehr in derselben Zeile wie .market-left/ .market-mid fand, aber noch nicht in den Mobile-Stapel-Modus wechselte - es landete dadurch verwaist rechtsbündig mit sichtbarer Lücke darunter): clamp() statt fixem Pixelwert lässt die Spalte oberhalb von 820px kontinuierlich mit der Fensterbreite mitschrumpfen, statt starr bei 400px zu bleiben - dadurch bleibt insgesamt mehr Platz für .market-right, der oben beschriebene verwaiste Zwischenzustand tritt nicht mehr auf. Obergrenze weiterhin 400px (der oben gemessene Worst-Case bleibt auf breiten Screens exakt erfüllt), Untergrenze 220px (kleiner als das - direkt oberhalb von 820px, wo ohnehin bald in den Mobile-Stapel-Modus mit width:100% gewechselt wird - dürfte auch der Kurstext selbst nicht mehr sinnvoll einspaltig Platz finden; ein Umbruch auf zwei Zeilen ist dort wie auf Mobile bereits akzeptiert, kein Overflow). 34vw als Mittelwert so gewählt, dass die Kurve bei exakt 820px (Breakpoint zum Mobile-Stapel-Modus) nah an der 220px- Untergrenze ankommt statt dort ebenfalls abrupt zu springen. */ --market-price-col-width: clamp(220px, 34vw, 400px); /* Analog zu --market-price-col-width: feste Breite der Namensspalte (.market-left bei Waren-/Aktienmarkt-Karten, .order-toggle-spacer darunter) bislang zweimal unabhängig als 380px hinterlegt (siehe Kommentar bei .market-card:has(.market-mid) .market-left weiter unten) - beide Stellen jetzt dieselbe Variable, verhindert künftiges Auseinanderlaufen. Ebenfalls clamp() statt fixem Wert aus demselben Grund wie oben (Nutzeranfrage 26.08.2026, "bei zwei Dritteln Fensterbreite sieht es teilweise nicht gut aus"). 24vw (nicht wie bei --market-price-col-width 34vw) - live nachgemessen bei 1000px Fensterbreite (dem konkret gemeldeten "verwaisten" Zwischenzustand): .market-mid (min-width 220px) + .market-right (~406px, von den Kaufen/Verkaufen-Buttons selbst vorgegeben, dort nicht angetastet) + zwei 8px-Gaps brauchen zusammen ~642px - erst ab einer .market-left-Breite von ca. 274px oder weniger bleibt bei 1000px genug Platz, damit .market-right in derselben Zeile bleibt statt verwaist umzubrechen. 24vw ergibt bei 1000px 240px (mit Puffer unter den 274px), bei 380px-Deckel weiterhin identisch zum bisherigen festen Wert auf breiten Screens (>1266px, wo 24vw > 380px). */ --market-left-col-width: clamp(200px, 24vw, 380px); --accent: #2f9e63; --accent-dark: #227a4c; --accent-light: #e6f5ec; --bg: #f5f7f6; --card: #ffffff; --text: #22292a; /* Nutzerreport 04.08.2026: normaler (nicht überschriftartiger) Text in dieser gedämpften Farbe wirkte auf vielen Screens zu blass, gerade bei kleiner Schrift (12-13px, z. B. .item-sub-Beschriftungen). Kontrast zu --card angehoben (4,6:1 → 7,0:1 - deutlich über der WCAG-AA-Mindestgrenze von 4,5:1), ohne den Farbton (gedämpftes Grün-Grau, passend zum übrigen Farbschema) zu verändern. */ --muted: #4f5c5a; --border: #e1e6e4; /* Kontrastaudit (06.08.2026, Nutzeranfrage "sorge dafür, dass der Kontrast sowohl im hellen als auch im dunklen Design gut ist") - vorher #c94f4f, als Text auf --card (weiß) nur 4,45:1 (unter der WCAG-AA- Mindestgrenze 4,5:1 für normal großen Text) - u. a. betroffen: Login-/ Registrierungs-Fehlermeldungen (#authError etc.), .warning-btn- Ruhezustand, .price-down. Minimal auf 4,93:1 nachgedunkelt, gleicher Farbton/gleiche Sättigung, kaum wahrnehmbarer optischer Unterschied. --down war schon immer identisch zu --danger (zwei Namen für denselben Wert, semantische statt farbliche Unterscheidung) und bleibt es. Der Dark-Mode-Wert unten ist NICHT betroffen - dort bereits 5,4-8,7:1 als Text auf --card, siehe die vielen dortigen Verwendungsstellen. */ --danger: #c54343; /* Vorher identisch zu --accent (#2f9e63) - als Text auf --card (weiß) nur 3,39:1. Betrifft nur .price-up; --accent selbst bleibt unverändert (dutzende andere Verwendungen als Rahmen/Icon-Farbe, dort unkritisch). Bewusst entkoppelt statt --accent selbst nachzudunkeln. */ --up: #257e55; --down: #c54343; /* Neu (06.08.2026, Kontrastaudit): dedizierte, THEMENUNABHÄNGIGE Hinter- grundfarben für Buttons mit weißer Schrift - ersetzen an den betroffenen Stellen die bisherige Wiederverwendung von --accent/ --accent-dark. Grund: --accent-dark ist im Light Mode absichtlich dunkler als --accent (für Hover-Verdunklung gedacht), im Dark Mode aber absichtlich HELLER als --accent (für Textlesbarkeit auf dunklem Hintergrund gedacht) - "weiße Schrift auf --accent/--accent-dark" traf dadurch in KEINEM Theme zuverlässig 4,5:1 (Light 3,39/5,31, Dark 3,00/2,09). Beide neuen Werte sind bewusst so gewählt, dass derselbe Hex-Code in beiden Themes funktioniert (weiße Schrift ≥5:1, sichtbar gegen --bg/--card in beiden Themes) - deshalb hier in :root definiert, ohne Override im Dark-Mode-Block unten. */ --btn-bg: #257e55; --btn-bg-hover: #22774f; --btn-danger-bg: #ba4545; --btn-danger-bg-hover: #a43d3d; /* Lager "fast voll" (12_UI_UX.md, Nutzeranfrage 03.09.2026) - eigene Zwischenstufe zwischen normal (--accent) und "voll"/pausiert (--danger). Wie --btn-bg oben bewusst themenunabhängig (weiße Schrift auf diesem Ton: ~5,0:1, in beiden Themes ausreichend), kein separater Dark-Mode- Override nötig. Trägt das weiße "!" auf .storage-warn-badge, deshalb an die 4,5:1-Kontrastgrenze für weiße Schrift gebunden - dafür zu dunkel/ gedämpft, um in der Lagerübersicht klar von --danger unterscheidbar zu sein (Nutzerreport 03.09.2026, "sieht fast identisch aus wie das rot"). --warning-fill (unten) ist die separate, hellere Füllfarbe für genau diesen textlosen Fall. */ --warning: #b45309; /* Nur für .progress-bar.near-full (kein Text auf der Leiste, keine 4,5:1-Bindung wie --warning oben) - deutlich helleres/kräftigeres Orange, damit die 90%-Frühwarnung auf der dünnen 8px-Leiste klar als Orange statt als weiteres Rot lesbar ist. Bewusst ebenfalls themenunabhängig (kein Text, kein Kontrastproblem in keinem Theme). */ --warning-fill: #f59e0b; /* Disabled-Button-Grauton war bisher überall hartkodiert (#cfd6d3/ #8b9591) ohne Dark-Mode-Gegenstück - im dunklen Design saß dieses helle Grau dadurch als einziges "leuchtendes" Element zwischen sonst überall nachgedunkelten Farben (Nutzerreport 21.08.2026, "nichts soll blenden"). Eigene Variablen statt direkter Farbwerte an jeder der betroffenen Stellen (button:disabled, button.secondary/.buy/.danger:disabled). Nutzeranfrage 02.09.2026 ("wie sähe es aus, wenn wir die WCAG-AA- Mindestgrenze einhalten würden") - #8b9591 lieferte auf #cfd6d3 nur 2,1:1 (WCAG erlaubt das zwar, da 1.4.3 inaktive/disabled Komponenten ausdrücklich ausnimmt, siehe Kontrastaudit-Kommentar oben, aber auf Wunsch trotzdem angehoben). --btn-disabled-bg bleibt unverändert, der Text nutzt jetzt --muted statt eines eigenen Grautons - keine neue Farbe, sondern dieselbe bereits etablierte gedämpfte Textfarbe wie überall sonst im Spiel, ergibt hier ≈4,7:1. */ --btn-disabled-bg: #cfd6d3; --btn-disabled-text: var(--muted); /* Nutzeranfrage 02.09.2026 - button.secondary (ursprünglich transparent mit grünem Rahmen/grüner Schrift, zwischenzeitlich ein Sand/Beige-Ton) auf ausdrücklichen Wunsch wieder auf denselben Grünton wie die übrigen Buttons zurückgesetzt ("so grün wie die anderen Buttons"), weiße Schrift statt der vorherigen dunklen. Dieselben Hex-Werte wie --btn-bg/--btn-bg-hover (siehe dortiger Kommentar: derselbe Wert funktioniert in beiden Themes). Kein separater Dark-Mode-Block mehr nötig, aus demselben Grund wie bei --btn-bg. (Das Admin-Live-Testfeld, das hier ursprünglich noch einen editierbaren Hex-String statt einer var(--btn-bg)-Referenz verlangte, ist seit 04.09.2026 wieder entfernt, siehe Nutzeranfrage "Secondary-Button- Farben (Live-Test) komplett aus Admin-Bereich entfernen".) */ --btn-secondary-bg: #257e55; --btn-secondary-bg-hover: #22774f; --btn-secondary-text: #ffffff; /* button.buy (Sofortkauf-Rahmenbutton) - Farbwert existierte bisher nur als hartkodierter Hex-Wert direkt in der button.buy-Regel, ohne Dark-Mode-Gegenstück (siehe dortiger Kommentar). Hier als Variable promoted, damit der Dark-Mode-Block unten einen helleren, auf --card (dunkel) lesbaren Ton definieren kann. */ --buy: #1b6fa8; --buy-light: #e8f2fa; /* MarketBorn-Wortmarke (Header/Login/E-Mail-Bestätigung, Redesign 09.08.2026): warmer Startton des "Born"-Farbverlaufs. Der Endton braucht keine eigene Variable, der Verlauf läuft direkt in --accent aus - die Wortmarke endet dadurch tatsächlich im Signalgrün der App statt in einem eigenen, unabhängigen Grün. Die Kursverlauf-Linie hinter dem Schriftzug braucht ebenfalls keine eigene Variable, die nutzt direkt --muted (passender gedämpfter Farbton als eigenständige Erfindung). */ --logo-spark: #f0862e; } /* Dunkles Farbschema (user request 28.07.2026), per Profil-Toggle wählbar - setTheme() setzt data-theme auf , Auswahl wird serverseitig pro Account gespeichert (players.theme), nicht nur lokal im Browser. */ :root[data-theme="dark"] { --accent: #34a873; --accent-dark: #56c891; --accent-light: #1b3a2c; --bg: #12171a; --card: #1c2226; --text: #e6ebe9; /* Gegenstück zur Light-Mode-Korrektur oben - dort dunkler, hier heller (Kontrast zu --card 5,9:1 → 8,1:1), gleiche Begründung. */ --muted: #aabcb7; --border: #2b3336; /* --danger/--up/--down bleiben hier unverändert (bereits 5,4-8,7:1 als Text auf --card/--bg, siehe Kontrastaudit-Kommentar oben) - nur der Light-Mode-Wert war zu blass. --btn-bg/--btn-bg-hover/--btn-danger-bg/ --btn-danger-bg-hover werden hier bewusst NICHT überschrieben (derselbe Wert funktioniert in beiden Themes, siehe Kommentar oben). */ --danger: #d97b7b; --up: #4cbd84; --down: #d97b7b; /* Helleres Blau als im Light Mode (dort #1b6fa8) - auf der dunklen Karte (--card #1c2226) lieferte der Light-Mode-Ton nur 2,97:1. */ --buy: #3da1d6; --buy-light: #153043; /* Deutlich dunkler als der helle Light-Mode-Ton (#cfd6d3 wäre hier die hellste Fläche im ganzen dunklen Design gewesen) - Text entsprechend umgekehrt heller als die Fläche, gleiches Prinzip wie --muted oben. --btn-disabled-text nutzt seit der Kontrast-Anhebung oben (Light Mode- Kommentar bei --btn-disabled-text) ebenfalls --muted statt eines eigenen Grautons (#7d8a88 lieferte hier nur 3,15:1) - --muted ist im Dark Mode bereits deutlich heller als --card/--btn-disabled-bg (siehe eigener Kontrastaudit-Kommentar oben), ergibt hier ≈5,7:1. */ --btn-disabled-bg: #333c40; /* Helleres Orange als im Light Mode (dort #f0862e) - Kontrast auf der dunklen Karte sonst zu gedämpft. */ --logo-spark: #ffa24e; } * { box-sizing: border-box; } /* Erzwungene vertikale Scrollbar (Nutzeranfrage 01.08.2026): ohne das erscheint/verschwindet die Scrollbar je nach Ansicht (z. B. eine kurze Liste vs. die Firmenzentrale mit vielen Firmen), wodurch die verfügbare Breite und damit das gesamte Layout leicht hin- und herspringt. Immer reserviert/sichtbar hält den Screen unabhängig vom Seiteninhalt identisch. Nur vertikal, wie ausdrücklich gewünscht - horizontales Scrollen bleibt unverändert (kein overflow-x hier gesetzt). */ html { overflow-y: scroll; } /* Eigene Scrollbar fürs ganze Fenster (Nutzeranfrage 25.08.2026) - dieselbe Optik, die zuerst nur für #mailboxList eingeführt wurde (siehe dort für die Firefox/WebKit-Doppelspur-Begründung), hier auf html erweitert, dem Element mit der oben erzwungenen Scrollbar. scrollbar-width/-color vererben sich als normale CSS-Eigenschaften ohnehin schon automatisch an jedes Kind-Element (auch #mailboxList) - die ::-webkit-scrollbar- Pseudo-Elemente dagegen nicht, die bleiben deshalb dort zusätzlich bestehen. */ html { scrollbar-width: thin; scrollbar-color: var(--btn-bg) transparent; } html::-webkit-scrollbar { width: 10px; } html::-webkit-scrollbar-track { background: transparent; } html::-webkit-scrollbar-thumb { background: var(--btn-bg); border-radius: 999px; } html::-webkit-scrollbar-thumb:hover { background: var(--btn-bg-hover); } /* Flex-Spalte über die volle Fensterhöhe, damit der Rechts-Footer (siehe #legalFooter) bei wenig Inhalt trotzdem am unteren Fensterrand steht und bei viel Inhalt normal darunter mitscrollt - ohne position:fixed, das sonst mit der mobilen Tab-Leiste und dem Tutorial-Panel um denselben Platz konkurrieren würde. */ body { margin: 0; font-family: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; background: linear-gradient(rgba(245, 247, 246, calc(1 - 0.95)), rgba(245, 247, 246, calc(1 - 0.95))), var(--bg) url("/assets/background.jpg") center / cover no-repeat fixed; color: var(--text); min-height: 100vh; display: flex; flex-direction: column; } /* Sprung-Link (Barrierefreiheits-Audit 22.08.2026, WCAG 2.4.1) - Standard- Muster: per absolute Positionierung und clip-artiges 1px-Fenster unsichtbar, solange er nicht fokussiert ist, bei Tab-Fokus springt er sichtbar oben links ins Bild. z-index 300 liegt über allem Bestehenden im Spiel (höchster bisheriger Wert war .modal-overlay mit 200), da der Link buchstäblich das allererste fokussierbare Element der Seite ist. */ .skip-link { position: absolute; top: -40px; left: 8px; z-index: 300; background: var(--btn-bg); color: #fff; padding: 10px 16px; border-radius: 8px; text-decoration: none; font-weight: 600; transition: top 0.15s ease; } .skip-link:focus { top: 8px; } /* Bugfix (Nutzerreport 27.08.2026, "seltsamer schwarzer Rahmen um die Firmen-Karte, kommt bei Escape") - main hat tabindex="-1" (siehe index.html), rein damit der Sprung-Link oben per focus() dorthin springen kann und ein per Escape geschlossener Dialog seinen Fokus sinnvoll zurückgeben kann (closeModalFocus(), ui-helpers.js - fokussiert modalReturnFocusEl zurück; war beim Öffnen des Dialogs zufällig main selbst aktiv, z. B. weil noch kein einzelnes Element den Fokus hatte, landet der Fokus beim Schließen wieder dort). Ohne eigene Regel zeigte der Browser dafür seinen Standard-Fokusrahmen um das komplette main - optisch wie ein sinnloser Rahmen um die gesamte Karte, obwohl main selbst nie per Tab erreichbar ist (tabindex="-1" schließt es aus dem normalen Tab-Fluss aus) und der Rahmen dadurch für sehende Tastatur-Nutzer keinen erkennbaren Zweck hat. outline:none entfernt nur diese eine, rein technische Fokussierung - der Sprung-Link selbst hat weiterhin seinen eigenen, bewusst sichtbaren :focus-Stil (siehe oben), und alle echten interaktiven Elemente (Buttons, Links, Eingabefelder) behalten ihren normalen Fokusrahmen unverändert. */ main:focus { outline: none; } :root[data-theme="dark"] body { /* War identisch zum Light-Mode-Deckkraft-Wert (0,05) - das Hintergrundbild blieb dadurch im dunklen Design praktisch unverändert hell und wirkte neben den sonst überall nachgedunkelten Flächen wie beleuchtet (Nutzerreport 21.08.2026, "nichts soll blenden"). Deutlich kräftigerer dunkler Schleier nur im Dark-Mode-Override, Light Mode bleibt unverändert bei 0,05. */ background: linear-gradient(rgba(18, 23, 26, calc(1 - 0.45)), rgba(18, 23, 26, calc(1 - 0.45))), var(--bg) url("/assets/background.jpg") center / cover no-repeat fixed; } /* Bugfix (Nutzeranfrage 20.08.2026, "Hintergrundbild scrollt auf Mobile ein bisschen mit"): background-attachment:fixed auf body selbst wird von mobilen Browsern nicht zuverlässig eingehalten - beim Scrollen (u.a. durch das Ein-/Ausblenden der Adressleiste, das den Viewport laufend neu vermisst) rutscht das Bild sichtbar mit. Auf schmalen Screens übernimmt stattdessen ein echtes position:fixed-Pseudoelement hinter dem gesamten Inhalt - das wird von mobilen Browsern zuverlässig fixiert, anders als eine reine background-attachment-Eigenschaft. body selbst bekommt hier nur noch die Fallback-Farbe (--bg) als eigenen Hintergrund, das Bild und der Deckkraft-Verlauf wandern komplett in dieses Pseudoelement. */ @media (max-width: 820px) { body { position: relative; background: var(--bg); } body::before { content: ""; position: fixed; inset: 0; z-index: -1; background: linear-gradient(rgba(245, 247, 246, calc(1 - 0.95)), rgba(245, 247, 246, calc(1 - 0.95))), var(--bg) url("/assets/background.jpg") center / cover no-repeat; } :root[data-theme="dark"] body::before { /* Gleicher stärkerer Schleier wie beim Desktop-Gegenstück oben. */ background: linear-gradient(rgba(18, 23, 26, calc(1 - 0.45)), rgba(18, 23, 26, calc(1 - 0.45))), var(--bg) url("/assets/background.jpg") center / cover no-repeat; } } header { background: var(--card); /* Gleicher Holzsteg wie section.card oben, hier als einzelne Kante (kein border-radius am Header, daher reicht das einfachere border-image statt der background-clip-Technik). 3px statt 4px (Nutzeranfrage 22.08.2026, "alle Rahmen einen px schmaler") - gilt einheitlich für die gesamte Holzsteg-Familie (header, mobile-tab-bar, section.card, .kpi je -1px; #legalFooter, bewusst schon vorher 1px dünner als die Karten, von 3px auf 2px). border-top zusätzlich zu border-bottom (Nutzeranfrage 22.08.2026, "auch am oberen Rand des Header") - dasselbe border-image gilt bereits für alle Seiten, die eine Breite/Style haben, daher reicht das einfache Ergänzen der zweiten Kante ohne die Gradient-Deklaration zu verdoppeln. */ border-top: 3px solid; border-bottom: 3px solid; border-image: linear-gradient(90deg, #8a6a49, #4c3a28) 1; /* Zurück auf 12px/20px (Nutzeranfrage 20.08.2026, "Logo wieder reduzieren wie es vorher war") - die kurzzeitige Reduktion auf 6px/10px (20.08.2026, "Abstand des Logos nach links, oben und unten darf gerne etwas geringer sein") diente ausschließlich dazu, die durch das inzwischen wieder zurückgenommene 1,5-fach vergrößerte Logo gewachsene Kopfzeilenhöhe zu kompensieren - mit dem Logo wieder bei 42.9px erübrigt sich der Grund dafür von selbst, ohne das reduzierte Padding würde die Kopfzeile sonst sogar kleiner als ursprünglich ausfallen. padding-right bleibt unverändert der laufzeit-gemessene Reserve-Wert weiter unten, hier nicht betroffen. */ padding: 12px 20px; /* Reserviert Platz für die fest positionierten Bedienelemente oben rechts (#langSwitch: Theme-Umschalter + Sprachflagge) - die sitzen bewusst außerhalb von
(siehe Kommentar dort), da der Header vor dem Login komplett ausgeblendet ist. Ohne diese Reserve lief der Header-Inhalt (allen voran #playerTag, dessen Breite vom Anzeigenamen abhängt) darunter und wurde verdeckt (Nutzer-Report 31.07.2026). Der Wert wird zur Laufzeit aus der GEMESSENEN Breite gesetzt (syncHeaderControlsReserve(), Nutzer-Report 03.08.2026): Vorher stand hier fest 74px - passend für die Flagge allein. Mit dem zweiten Button reichte das nicht mehr und der Profil-Button wurde überlagert. Ein neu geratener Festwert hätte beim nächsten Element wieder gebrochen. */ padding-right: var(--header-controls-reserve, 74px); display: flex; align-items: center; justify-content: space-between; flex-wrap: wrap; gap: 10px; position: sticky; top: 0; z-index: 10; } .header-left { display: flex; align-items: center; gap: 12px; flex-wrap: wrap; } /* Reiner Durchreich-Wrapper auf Desktop (siehe HTML-Kommentar bei #headerWarnGroup) - beide Warn-Buttons bleiben dadurch unverändert direkte Flex-Kinder von .stats. Erst die Mobile-Media-Query weiter unten macht daraus eine echte kleine Flex-Zeile. */ .header-warn-group { display: contents; } header h1 { font-size: calc(17px + 1pt); margin: 0; /* Wortmarke ist seit 13.08.2026 (Nutzeranfrage, "Logo und Text darunter zu einer Bilddatei zusammenfügen") das einzige Kind - der Untertitel lebt seither direkt im SVG als zweites -Element statt als eigenes, separat positioniertes DOM-Element (siehe #logoBtn-Markup), daher genügt hier ein einfacher Block statt der vormaligen flex-direction:column-Stapelung zweier Kinder. */ display: block; /* Logo springt bei eingeloggten Spielern zum Dashboard (Nutzeranfrage 06.08.2026) - reines

, kein