/* ═══════════════════════════════════════════════════════════════ SETZZ 3.0 · Stylesheet Three-zone layout: left rail (48px) + left panel (220px) + board (flex) + right panel (240px, on-click only). Design language: near-black surfaces, single amber signal color, hairline borders, 0px radius, three type roles: display → Rajdhani label → JetBrains Mono data → JetBrains Mono ═══════════════════════════════════════════════════════════════ */ :root { /* NEU (2026-08-19, "acht Korrekturen", Punkt 5), GEPRÜFT UND EINGESCHRÄNKT (2026-08-19, Folgerunde): sagt dem Browser, dass die Seite ein dunkles Farbschema erwartet — der einzige Hebel, den CSS für BROWSER-EIGENE, nicht stylebare Elemente hat. WIRKT NICHT auf das Datalist-Popup, das der Auslöser für diese Regel war (Source/Tool, AI Model im Detail-Panel, `` + ``) — SimplifyerX hat auf Staging in beiden Themes geprüft: die Liste bleibt schwarz mit weißer Schrift, kein Unterschied. Chromium rendert Datalist-Vorschläge über denselben internen Autofill-Popup-Mechanismus wie Adress-/Formular- Autovervollständigung, NICHT über den regulären Formular-Rendering- Pfad, den `color-scheme` sonst steuert — bestätigt live: der Wert selbst steht korrekt am `:root` und wechselt mit dem Theme (getComputedStyle(document.documentElement).colorScheme, gemessen "dark" bzw. "light"), Chrome (hier Chromium 148) unterstützt die Eigenschaft grundsätzlich seit Version 81 — die Regel selbst ist also nicht falsch, sie hat nur keinen Empfänger für DIESEN Fall. Für das Datalist-Popup gibt es keine CSS-Lösung, siehe Backlog ("Auswahllisten … nicht gestaltbar") — nur ein eigenes Popover kann es farblich anpassen. BLEIBT TROTZDEM: zwei Scrollbereiche im Stylesheet haben KEINE eigene scrollbar-color/-width-Regel (.pdf-canvas-host bei gezoomtem PDF, .list-table-wrap bei breiten List-Karten-Tabellen) — alle anderen ~44 Scrollbereiche sind bereits einzeln durchgestylt und von dieser Regel unberührt. Für diese zwei bewirkt color-scheme, dass der native Browser-Scrollbalken dem Theme folgt statt einem harten Vorgabewert — nicht sichtbar per Screenshot bestätigt (native Scrollbalken-Bemalung ist außerhalb des per CSSOM Messbaren), aber die Kaskade dafür ist eindeutig (keine überschreibende Regel vorhanden, Chromium-Standardverhalten seit Version 89 folgt color-scheme für unbehandelte Scrollbalken). */ color-scheme: dark; /* surfaces */ --bg: #292929; /* app canvas */ /* GEÄNDERT (2026-08-04, Nutzer-Vorgabe): war #060607. WICHTIG: dies ist die GLOBALE Variable, nicht nur der Wert für .floating-panel aus dieser Runde — sie wird bereits an vielen weiteren, vorbestehenden Stellen im Dark Theme verwendet (u.a. Medien-Weiten, Selects, World-Kacheln ohne Cover, Preset-Icon-Hintergründe). Die Änderung wirkt dort überall mit, nicht nur bei den schwebenden Panels. */ --bg-deep: #232323; /* media wells */ --panel: #363636; /* panel body */ --panel-2: #17171b; /* raised chips, list rows */ --line: #494949; /* hairline border */ --line-soft: #1c1c21; --asset-outline: #3a3a3a; /* fine outline around uploaded assets */ /* NEU (2026-08-13, Nutzer-Vorgabe/SimplifyerX): eigene Tokens statt --panel/--panel-2 wiederzuverwenden — --panel-2 haengt an ~40 anderen Stellen (Hover-Flaechen app-weit), eine Wertaenderung dort haette weit ueber die Asset-Zeilen hinausgewirkt. Normale Zeile jetzt deutlicher heller als --bg (1.52:1 statt vorher 1.20:1 zwischen --bg und --panel) — sonst verschwimmt die Liste zur Flaeche. Ausgewaehlte Zeile deutlich dunkler als die normale Zeile (1.85:1). Enthaelt keine Akzentfarbe. */ --asset-row-bg: #454545; --asset-row-selected-bg: #181818; /* NEU (2026-08-15, Nutzer-Vorgabe/SimplifyerX, Light-Theme-Grundflaechen- Runde): eigener Token fuer Eingabefelder (.rp-input/.rp-textarea/ .rp-select), vorher teilten sie sich var(--bg) mit der App-Grundflaeche — im Light Theme praktisch ununterscheidbar (siehe dort). Dark bleibt bewusst UNVERAENDERT: derselbe Wert wie --bg, das heutige Verhalten (Feld = Grundflaeche) war im Dark Theme nie das gemeldete Problem. */ --field-bg: var(--bg); /* NEU (2026-08-15, Feldfarben-Runde): eigener Hover-Ton fuer Felder, Dark bewusst UNVERAENDERT — Sprung --field-bg(=--bg) -> --panel ist hier schon moderat (#292929 -> #363636), kein gemeldetes Problem. */ --field-hover-bg: var(--panel); /* ink */ --ink-hi: #ececec; /* NEU (2026-08-12, Nutzer-Vorgabe): Hierarchie-Stufe ÜBER --ink — "hier bist du gerade" (aktive Auswahl, primäre Überschrift im Fokus, aktiver Zustand). Kein Ersatz für --amber: Amber bleibt die Signalfarbe für Interaktion/Akzent, --ink-hi ist reine Hierarchie. Nicht vermischen. */ --ink: #c9c9c9; /* primary text */ --ink-dim: #9a9aa2; /* secondary */ --ink-faint: #999999; /* tertiary / placeholders */ /* signals */ --amber: #C8A23F; --amber-hi: #ddbb5f; --amber-dim: rgba(200,162,63,.14); --green: #46d160; --red: #ff5c4d; /* elevation — panels and sidebar icons share one shadow so a theme only has to define it once */ --panel-shadow: 6px 6px 6px rgba(0,0,0,0.1); --tile-shadow: 3px 6px 6px rgba(0,0,0,0.25); --overlay-rgb: 6, 6, 7; /* rgb triplet behind media-control chips, popovers, view-label gradient */ /* NEU (2026-08-13, Tooltip-Umbau, SimplifyerX-Vorgabe): eigene Tokens statt Literalen in .setzz-tooltip, damit eine spaetere Aufspaltung nach Theme keine Regel-Suche braucht, nur diese zwei Zeilen (hier und im [data-theme="light"]-Block unten). Heute BEWUSST in beiden Themes identisch — keine vergessene Anpassung. GEAENDERT (2026-08-13, zweite Runde): --tooltip-fg #cccccc → #ffffff — 2.21:1 war schlechter als die diesen Morgen als "kaum lesbar" korrigierten Feldbeschriftungen (2.37:1). #ffffff ist der hellste ueberhaupt moegliche Wert und bleibt bei 3.54:1 unter AA (4.5:1) — das ist gegen #888888 nicht erreichbar, siehe Kontrast-Kommentar bei .setzz-tooltip. */ --tooltip-bg: #888888; --tooltip-fg: #ffffff; /* type GEÄNDERT (2026-08-10): --f-display Sofia Sans Condensed → Rajdhani, --f-data Space Mono → JetBrains Mono. Ausgeliefert werden nur Rajdhani 500/600 (siehe fonts.css für die Gewichts-Begründung). --f-data UND --f-label zeigen jetzt auf dieselbe Familie. Die Variablen bleiben trotzdem GETRENNT, und das ist der Punkt: sie unterschieden bis hierher an zwei sichtbaren Stellen zwei Dinge — im Detail-Panel Feldname (.rp-label, data) gegen Feldwert (.rp-input, label), und im Zoom-HUD den Wert (.zoom-hud-pct, data) gegen die Knöpfe (.zoom-hud-btn, label). Diese Unterscheidung verschwindet optisch, bleibt aber strukturell erhalten: ein einziger geänderter Wert hier holt sie zurück, ohne 190 Fundstellen anzufassen. */ --f-display: "Rajdhani", sans-serif; --f-label: "JetBrains Mono", monospace; --f-data: "JetBrains Mono", monospace; /* ── Button-Groessen-Tokens ──────────────────────────────────── NEU (2026-08-12, Sitzung A / Etappe 1 des Button-System-Umbaus). WARUM ES DIESE TOKENS GIBT — das ist der eigentliche Punkt: Am 2026-07-18 wurde ein Button-Styleguide festgelegt (32/24px, Icon ~55%, Radius 0) und in drei Commits umgesetzt (fbd4dd6, d93423b, 89abae0). ZWEI TAGE SPAETER war er gebrochen: .row-ctrl-btn ging am 20.07. in einem Sammel-Commit (69a73b0, "diverse CSS-Anpassungen") kommentarlos von 32px auf 46px. Die Ursache war nicht Unachtsamkeit, sondern die Bauform: der Styleguide von 2026-07-18 hat SIEBEN EINZELNE KLASSEN je einzeln auf dieselben Werte gesetzt. Keine Basisklasse, kein Token. "32px" stand danach 33x woertlich im CSS und sah aus wie jede andere Zahl. Wer eine davon aendert, aendert eine Zeile — nichts sticht heraus. Farben laufen in SETzz seit Monaten NICHT auseinander. Der Grund ist genau dieser: sie stehen als Tokens einmal da. Groessen hatten bis heute kein einziges Token (nachgemessen 2026-08-12: 49 CSS- Variablen definiert, davon 0 fuer Groessen) — und sind auf 23 Kantenlaengen und 15 Icon-Groessen auseinandergelaufen. Ab hier gilt: eine Abweichung ist "width: 46px" mitten unter lauter var(--btn-size). Sie taucht im Diff auf, statt sich zu tarnen. ETAPPE 1 (dieser Stand): eingefuehrt, von NIEMANDEM genutzt. Der Fingerabdruck (docs/baselines/buttons.json) muss unveraendert bleiben — das ist der Beweis vor der Umstellung. */ --btn-size: 32px; /* Werkzeug/Icon-Button, Standard */ --btn-size-sm: 24px; /* Werkzeug/Icon-Button, kompakt (enge Menuezeilen) */ --btn-icon: 18px; /* Icon im Standard-Button (~55%) */ --btn-icon-sm: 14px; /* Icon im kompakten Button (~58%) */ /* GEÄNDERT (2026-08-13, Nutzer-Vorgabe/SimplifyerX): --btn-pad war EINE Groesse fuer alle Textknoepfe. Jetzt drei Stufen. Der bisherige Wert ist unveraendert die mittlere Stufe — dadurch aendert sich an den Dialog-Knoepfen (Save/Cancel) nichts, nur small/large kommen dazu. Small ersetzt die bisher HART CODIERTEN 9px/3px-9px/6px-12px im Assets-Manager (die sich damit jeder Messung entzogen), large traegt die Wichtigkeit des SAVE-Knopfes ueber die Flaeche statt ueber eine eigene dritte Variante. */ --btn-pad-sm: 4px 10px; --btn-pad-md: 8px 16px; /* = frueher --btn-pad, unveraendert */ --btn-pad-lg: 12px 22px; /* GEÄNDERT (2026-08-13, Nutzer-Vorgabe, vierte Runde): 9/10/13 → 10/12/14. Vorher am gerenderten Knopf gemessen: die Hoehe waechst dadurch um +1.45px (sm/lg) bzw. +2.9px (md) — RESET/SAVE im BOARD-SETTINGS-Panel gehen von 24.7/34px auf ~26.1/37px, beide Stufen gemeinsam, der Abstand zueinander bleibt erhalten (siehe Bestandsaufnahme). */ --btn-fs-sm: 10px; --btn-fs-md: 12px; --btn-fs-lg: 14px; --btn-gap: 6px; /* Abstand zwischen benachbarten Buttons */ /* NEU (2026-08-12, Etappe 4): Hauptaktion ist bewusst NICHT aus --ink/--bg abgeleitet — das wuerde sich mit dem Theme umkehren (in Dark waere --ink ein helles Grau, das Ergebnis ein HELLER Knopf mit dunklem Text — exakt das alte Weiss-auf-Dunkel-Muster, das die Vorrunde an .rp-save bewusst wegkorrigiert hat). KORRIGIERT (2026-08-13, Nutzer-Vorgabe/SimplifyerX, zweite Runde): GENAU DAS war der Fehler — nicht am Muster selbst, sondern daran, dass es fuer BEIDE Themes galt. Befund: ein Knopf wirkt als Bedienelement, wenn er im GEGENSATZ zur Umgebung steht, nicht im Einklang. Der alte fixe Wert (#000, beide Themes) traf das nur im Light Theme zufaellig richtig (schwarz auf hellem Panel = Kontrast) — im Dark Theme war er falsch (schwarz auf dunklem Panel = verschwimmt). Jetzt bewusst PRO THEME verschieden, mit vertauschten Rollen: Dark bekommt einen HELLEN Knopf (dieselbe Umkehr, die vorher schon einmal am SAVE-Knopf allein stand, siehe Kommentar oben — jetzt trägt sie das ganze System, kein Ausreisser mehr). Werte = die bestehenden --ink-Toene beider Themes, nicht neu erfunden. */ --btn-primary-bg: #c9c9c9; --btn-primary-fg: #1a1a1a; /* Hover geht zum Extrem (Nutzer-Vorgabe): Dark heller bis Weiss, Light dunkler bis Schwarz. Die Textfarbe bleibt dieselbe wie im Ruhezustand — #1a1a1a auf Weiss und #ececec auf Schwarz sind beide >17:1, ein eigener Hover-Textton ist nicht noetig. */ --btn-hover-bg: #ffffff; /* NEU (2026-08-13, zweite Runde): eigener, THEME-UNABHAENGIGER Hover nur fuer .btn-danger (das "X"). Haengte bisher an --btn-hover-bg — mit dessen Umkehr waere Rot im Dark Theme auf Weiss gelandet (3.05:1, unter AA). Alter gemeinsamer Wert, jetzt entkoppelt: Rot bleibt in beiden Themes auf dunklem Grund (4.97:1 / 4.50:1 gegen --red). */ --btn-danger-hover-bg: #262626; /* NEU (2026-08-13): Rahmen der Variante "extra". EIN Wert fuer beide Themes, und das ist kein Versehen: #8a8a8a liegt zwischen den Panel-Hintergruenden beider Themes und ist dadurch in Dark HELLER als das Panel (3.50:1 gegen --panel, 4.21:1 gegen --bg) und in Light DUNKLER (3.45:1 / 3.28:1) — die geforderte Umkehr entsteht von selbst, ohne zweite Definition. Bewusst schwaecher als --ink-dim (4.33:1 / 5.10:1), aber ueberall ueber 3:1: der Rahmen soll zeigen, dass DIESER Knopf wichtiger ist als die anderen — dass es ueberhaupt ein Bedienelement ist, traegt seit dieser Runde der Schatten. UNVERAENDERT in dieser Runde: traegt die "Gegensatz zur Umgebung"- Logik bereits seit letzter Runde, siehe Nutzer-Bestaetigung 2026-08-13. */ --btn-extra-border: #8a8a8a; --gap: 14px; --pad: 10px; --rail-w: 54px; /* GEÄNDERT (2026-08-12, Nutzer-Vorgabe): war 48px */ --demo-bar-h: 41px; /* NEU (2026-08-16): gemessene Hoehe von .demo-bar (Buttons bestimmen sie, nicht die Textzeile) — zentral, damit .topnav (siehe dort) nicht auseinanderlaufen kann */ --left-panel-w: 220px; --right-panel-w: 350px; /* NEU: BOARD Setting — vier unabhängige Gap-Stufen (docs/setzz-board- customizing-notes.md). "Medium" = der jeweils bisherige, bestehende Wert dieses Abstands (dedizierte eigene Variable statt Wiederverwendung von --gap, das an anderen, unabhängigen Stellen — Panel-Padding, Group-Wrap-Margin — schon anderweitig genutzt wird und dafür unverändert bleiben soll). Werte werden zur Laufzeit per JS (applyGapSettings(), app.js) je nach gespeicherter Stufe überschrieben; diese hier sind die Defaults = "Medium". */ --gap-card: 0.65rem; /* CARD Gap: vertikal zwischen Cards in einer Column (.col-body) */ --gap-col: 14px; /* COL Gap: horizontal zwischen Columns in einem SET (.group-body) */ --gap-set: 50px; /* SET Gap: horizontal zwischen SETs in einer Row (.group-row) */ --gap-row: 50px; /* ROW Gap: vertikal zwischen Rows (.columns-scroll) */ /* NEU (2026-07): SET-eigenes Innen-Padding, jetzt einstellbar statt fest (siehe .group-wrap) — h = links+rechts, v = oben+unten. */ --pad-set-h: 20px; /* SET h-padding: links/rechts innerhalb der SET-Karte (.group-wrap) */ --pad-set-v: 30px; /* SET v-padding: oben/unten innerhalb der SET-Karte (.group-wrap) */ --pad-card: 5px; /* CARD Padding: Innenabstand jeder Card (.panel) */ /* NEU: Custom Board-Hintergrund — Tint-Ebene über einer garantierten Basis (siehe .workspace unten). Transparent = kein Tint, Standardzustand ohne gespeicherte Einstellung. Wird je nach aktivem Theme unterschiedlich gesetzt (applyBoardBackgroundTint(), app.js), daher hier nur ein neutraler Default. */ --board-bg-tint: transparent; /* NEU (2026-08-27, Lightbox-Hintergrund): dieselbe Board-Farbe wie --board-bg-tint, aber mit einer EIGENEN, fest gewählten Deckkraft (.90) statt der vom Nutzer gewählten Board-Deckkraft — siehe applyBoardBackgroundTint() (app.js) für die Berechnung und den Bericht dieser Runde für die Kontrast-Messung, die zu .90 führte. Default hier ist WORTGLEICH der bisherige feste Wert von .lightbox (rgba(var(--overlay-rgb), .95)) — ohne gesetzten Board-Farbton bleibt die Lightbox dadurch unverändert, --overlay-rgb macht den Default bereits automatisch hell/dunkel-spezifisch, keine zweite Deklaration im [data-theme="light"]-Block nötig. */ --board-bg-tint-lightbox: rgba(var(--overlay-rgb), .95); /* NEU (2026-08-27, Lightbox-Bedienelemente einheitlich): gemeinsame Platte für ALLE DREI Bedienelemente (Pfeile, Schließen, Beschriftung) — Entscheidung SimplifyerX, Variante (a). Bewusst NICHT aus --board-bg-tint/-lightbox abgeleitet: genau das Ableiten war das Problem (Farbe, die bei einem Board-Ton trägt, versagt beim nächsten — siehe Bericht der Hintergrund-Runde, "kein Alpha-Wert kann das für gesättigte Töne lösen"). --overlay-rgb macht sie automatisch hell/dunkel-spezifisch, aber IMMER fest, nie vom Board abhängig — das ist die eigentliche Entkopplung, nicht die Farbe an sich. .8 GEMESSEN (Bericht dieser Runde): niedrigster Wert, bei dem der Kontrast Symbol-gegen-Platte in JEDER getesteten Kombination (vier Board-Töne × beide Themes) über 4,5:1 bleibt — niedriger (wie das bisherige .6 der Pfeile) unterschreitet das bei hellen bzw. gesättigten Tönen deutlich. */ --lightbox-plate-bg: rgba(var(--overlay-rgb), .8); /* NEU (2026-07): analoger Tint für den CARD-Hintergrund (.panel) — legt sich über die theme-eigene --panel-Basisfarbe, siehe applyCardBgTint(), app.js. */ --card-bg-tint: transparent; /* NEU (2026-08-24, Teil 4): Zebra-Ueberlagerung fuer alternierende List-Zeilen (.list-td:nth-child(even), siehe dort) — hell oder dunkel, je nach applyCardBgTint()'s Helligkeitsmessung. transparent als Default, bis das Skript einmal gelaufen ist (analog --card-bg-tint oben). */ --card-bg-zebra: transparent; /* NEU (2026-09-04, "Der Codeblock folgt der Kartenflaeche"): anders als --card-bg-zebra kein "transparent"-Default — der Codeblock braucht seine Flaeche auch ohne gesetzten Kartenton (siehe applyCardBgTint(), app.js). Hier der DARK-Default (dieses :root ist das Dark Theme, siehe Kopfkommentar der Datei): ungetoentes --panel (#363636) ist dunkel, also aufhellen. Light-Theme-Gegenwert siehe :root[data-theme="light"] weiter unten. Nur ein Platzhalter, bis das Skript einmal gelaufen ist -- praktisch sofort beim ersten Render. */ --card-bg-code: rgba(255, 255, 255, .035); /* NEU: die Basis-Ebene selbst ist jetzt ebenfalls dynamisch — sehr dunkles Grau OHNE Custom-Farbe (damit graue CARDS sichtbar bleiben), aber reines Schwarz, SOBALD eine Custom-Farbe aktiv ist (damit der Tint wie ursprünglich gedacht darüber blendet, siehe applyBoardBackgroundTint()). */ --board-bg-base: #141414; /* NEU: automatischer Kontrast-Ausgleich für Text/Icons AUSSERHALB der Cards (Row-Titel, Set-Beschriftung, sonstige lose Board-Elemente direkt auf dem Workspace-Hintergrund — siehe docs/setzz-board- customizing-notes.md, Abschnitt "Ergänzung"). Default = die ganz normalen, theme-eigenen Ink-Farben (kein Unterschied ohne Custom- Farbe); applyBoardBackgroundTint() (app.js) überschreibt beide Variablen per Inline-Style, sobald eine Custom-Farbe aktiv ist und die berechnete Mischfarbe einen Farbsatz-Wechsel verlangt. */ --board-ink-faint: var(--ink-faint); --board-ink-dim: var(--ink-dim); --board-ink: var(--ink); /* NEU: Transparenz von SET-Style "Border"/"Background" (Light/Dark getrennt einstellbar, siehe BOARD SETTINGS → "SET Style Transparency"). Default 0.3 = bisheriger fest kodierter Wert. */ --set-style-alpha-light: 0.3; --set-style-alpha-dark: 0.3; /* NEU: "CARD Style Custom" (docs/setzz-card-style-and-hide-notes.md) — Ersatz-Hintergrund für CARDS mit aktivem "Card Style: Custom" (⋮-Menü). Wird je nach aktivem Theme gesetzt (applyCardStyleCustomTint(), app.js); Default hier nur ein neutraler Platzhalter, bevor JS läuft. */ --card-style-custom-bg: var(--panel); /* ══ Layer-Ordnung (2026-08, docs/setzz-floating-panels-notes.md) ══ Benannte z-index-Stufen statt verstreuter Rohzahlen — genau EINE Quelle für die globale App-Chrome-Reihenfolge, damit eine künftige neue Ebene bewusst einsortiert wird statt geraten zu werden (dasselbe Prinzip wie bei den handgepflegten Listen im JS, nur mit Zahlen). Absteigend sortiert, oben = vorne: 0. --z-tooltip NEU (2026-08-13, Tooltip-Umbau Etappe 2). Ueber JEDER anderen Stufe, auch Confirm Dialog: ein title- tragendes Element kann in jeder Ebene stecken (ein Knopf in einem Confirm-Dialog hat z.B. title="..."), der Tooltip muss also immer oben schwimmen, unabhaengig davon, was gerade offen ist. 1. --z-confirm-dialog Die generische confirmDialog()-Modal — wird von sehr vielen, nicht einzeln auditierbaren Stellen aufgerufen (auch VERSCHACHTELT in anderen Ebenen, z.B. innerhalb des MD-Import-Dialogs oder während einer Free-Board-Marquee-Auswahl). Deshalb bewusst der einzige sichere Standard: IMMER zuoberst, auch über der Free-Board-Gesten-Ebene (9996–9999, siehe unten), die selbst unverändert bleibt. Kein Sonderfall soll sie je verdecken können. 2. --z-modal-dialog Eigenständige, block­ierende App-Dialoge (aktuell: MD-Import). Unter Confirm Dialog, weil genau dieser Dialog selbst wieder confirmDialog() aufruft (Ersetzen-Bestätigung) und darüber sichtbar bleiben muss. 3. --z-toast Bewusst über Floating Panels UND über der Immersive-View-Stufe: beide haben nahezu blickdichte Blenden (Lightbox/Focus-Overlay 90–95% Opazität), die einen Toast sonst spurlos verschlucken würden — der unauffälligste aller Fehler, weil man (anders als beim Dialog) gar nicht merkt, dass etwas fehlt. Unter Dialog/Modal: eine passive Meldung darf nie die Buttons einer aktiven Entscheidung verdecken. 4. --z-immersive-view Lightbox + Focus-Overlay (gemeinsame Stufe, da beide exklusiv sind und nie gegeneinander sortiert werden müssen). Aktuell löst keine Lightbox-Aktion einen verschachtelten Dialog aus — die Confirm-Dialog-Regel oben deckt diesen Fall aber vorsorglich ab, falls sich das künftig ändert. 5. --z-popover-menu Alle Kontextmenüs/Popover (Karten-⋮-Menü, Ratio/Fields/Meta-Editor, Share-Link/Group-Template/Color) in einer Stufe — sie schließen sich per Outside-Click gegenseitig, brauchen also keine eigene Reihenfolge, nur Vorrang vor Floating Panels. 6. --z-floating-panel Basis der schwebenden Panels (wie bisher; einzelne Panels erhalten per JS – floatingZTop, app.js – weiterhin aufsteigende Werte ab dieser Basis). Bleibt über Board/Rail/ angedockten Panels, aber unter allen Stufen 1–5 — genau das war vorher NICHT der Fall (Confirm Dialog, Toast, Popover und Lightbox/Focus-Overlay standen alle unter 2000 und wurden von jedem offenen Floating Panel verdeckt). NICHT Teil dieser Ordnung: rein lokale/gepaarte Stacking-Contexts (z.B. .board-overlay↔.right-panel, Resize-Griffe innerhalb eines Panels/COLs, Medien-Kontrollen innerhalb einer Card, Dashboard-Kachel- interne Ebenen, die Free-Board-Gesten-Ebene 9996–9999) — deren rohe Zahlen bleiben unverändert, da sie nur gegen ihre unmittelbare Umgebung sortieren, nicht gegen die globale App-Chrome-Reihenfolge. */ --z-floating-panel: 2000; /* unverändert — muss mit FLOATING_Z_BASE in app.js synchron bleiben */ --z-popover-menu: 3000; --z-immersive-view: 4000; --z-toast: 5000; --z-modal-dialog: 6000; --z-confirm-dialog: 10000; /* > 9999, damit auch über der Free-Board-Gesten-Ebene */ --z-tooltip: 10001; /* > --z-confirm-dialog, siehe Layer-Ordnung oben */ } /* ── Light theme — same structure, no rounded corners (matches the dark theme exactly), separation via soft shadows instead of borders. Sidebar shares the page background rather than a distinct shade. Toggled via [data-theme="light"] on . ── */ :root[data-theme="light"] { /* GEÄNDERT (2026-08-15, Nutzer-Vorgabe/SimplifyerX, zweite Runde): war #f9f9f9 (1.05:1 gegen Weiss — kaum wahrnehmbar), dann kurz #f0f0f0 versucht und wieder verworfen (liess --ink-dim auf --bg unter 4.5:1 fallen, 4.84 -> 4.47). Diesmal --bg UND --ink-dim gemeinsam bestimmt, siehe dortiger Kommentar. #e6e6e6 gegen Weiss: 1.25:1 — deutlich wahrnehmbar, naeher an der Elevations-Stufe des Dark Themes selbst (--bg/--panel dort: 1.20:1) als am vorherigen, zu leisen Versuch. */ /* Gegenstück zu color-scheme:dark auf :root — siehe dort für den vollständigen, geprüften Befund (wirkt NICHT auf das Datalist- Popup, das der Auslöser war; bleibt für zwei ungestylte native Scrollbalken). */ color-scheme: light; --bg: #e6e6e6; --bg-deep: #ececec; --board-bg-base: #f0f0f0; --panel: #ffffff; --panel-2: #fbfbfb; /* Gegenwert zum Dark-Default im :root oben (--card-bg-code): ungetoentes --panel ist hier weiss, also verdunkeln statt aufhellen. */ --card-bg-code: rgba(0, 0, 0, .035); --line: #e2e2e2; --line-soft: #ececec; --asset-outline: #ffffff; /* fine outline around uploaded assets */ /* NEU (2026-08-13): normale Zeile bleibt am physikalischen Maximum (#ffffff, kann nicht heller werden) — die eigentliche Trennung leistet hier die dunklere Auswahl-Flaeche (1.27:1 zur Zeile, 1.21:1 zum Panel-Hintergrund). Siehe Dark-Theme-Definition oben. */ --asset-row-bg: #ffffff; --asset-row-selected-bg: #e4e4e4; /* NEU (2026-08-15): eigene, dunklere Flaeche fuer Eingabefelder — siehe --field-bg im :root oben. Muss unter --bg UND unter --panel(weiss) liegen, damit ein leeres Feld allein durch seine Flaeche erkennbar ist (Nutzer-Befund: "Current password"/"New password" waren ohne Inhalt fast unsichtbar). Kontrast --ink-dim (neuer Wert unten) auf diesem Feld: 4.97:1 — ueber 4.5:1 mit Reserve, nicht auf Kante. GEÄNDERT (2026-08-15, gleicher Tag, Folgerunde): #dedede -> #eeeeee, Nutzer-Wunsch "weicher". ACHTUNG: liegt jetzt UEBER --bg (#e6e6e6) statt darunter — Feld ist die hellere Flaeche, nicht mehr die dunklere. --bg vs Feld nur noch 1.076:1 Kontrast (nahe am vom Nutzer selbst genannten "praktisch unsichtbar"-Wert 1.05). Exakt wie angefragt umgesetzt, nicht eigenmaechtig nachjustiert — siehe Meldung an den Nutzer. */ --field-bg: #eeeeee; /* NEU (2026-08-15, gleiche Runde): eigener Hover-Ton statt Sprung auf --panel (#ffffff, reines Weiss) — der wirkte laut Nutzer-Befund wie ein Wechsel der Flaeche, nicht wie Hover. Kleiner, spuerbarer Schritt dunkler als --field-bg (#eeeeee -> #e8e8e8), bleibt erkennbar eigene Feld-Flaeche statt zur Panel-Flaeche zu springen. */ --field-hover-bg: #e8e8e8; /* GEÄNDERT (2026-08-15): --ink-dim war #6e6e6e — auf dem gedunkelten --bg (#e6e6e6, s.o.) waere das 4.09:1, unter AA. Gemeinsam mit --bg neu bestimmt: #5c5c5c haelt 5.36:1 auf --bg und 4.97:1 auf --field-bg, beides mit Reserve statt auf der Kante. Bleibt klar von --ink (#1a1a1a) unterschieden (2.60:1 Kontrast dazwischen) — die Hierarchie-Stufe geht nicht verloren. */ --ink: #1a1a1a; --ink-hi: #1a1a1a; /* = --ink: Light braucht (noch) keine eigene Hierarchie-Stufe, siehe Bericht */ --ink-dim: #5c5c5c; --ink-faint: #9a9a9a; /* NEU (2026-08-13, zweite Runde): Umkehr-Rollen fuer Light. Dark war bisher (zufaellig) schon richtig gepolt (schwarz auf hellem Panel = Kontrast) — Light bekommt jetzt bewusst die Gegenrichtung: dunkler Knopf normal, im Hover zum Extrem Schwarz. Siehe Begruendung + Kontraste im Dark-Block oben. */ --btn-primary-bg: #1a1a1a; --btn-primary-fg: #ececec; --btn-hover-bg: #000000; --amber: #C8A23F; --amber-hi: #a8760f; --amber-dim: rgba(138,93,0,.10); --green: #1f9e44; --red: #d63a2e; --panel-shadow: 0 6px 18px rgba(0,0,0,0.05); --tile-shadow: 0 3px 7px rgba(0,0,0,.12); --overlay-rgb: 255, 255, 255; /* Bewusst identisch zum Dark-Block oben — siehe Kommentar dort. */ --tooltip-bg: #888888; --tooltip-fg: #ffffff; } * { margin: 0; padding: 0; box-sizing: border-box; } button { font: inherit; color: inherit; background: none; border: 0; cursor: pointer; } /* NEU (2026-08-19, "Detail-Panel neu ordnen", Punkt d): Kontrollkästchen trugen app-weit das native Browser-Blau — die einzige Farbe im ganzen Werkzeug, die nicht aus der Projektpalette stammt (gemessen am 2026-08-19: accent-color:auto, appearance:auto an allen Fundstellen, es gab NIRGENDS eine Checkbox-Regel). EINE Regel fuer alle acht Fundstellen statt acht Einzelregeln — sie sind ueber vier Dateien verstreut (AI/Real und Custom-Detail-Felder im Detail-Panel, Referenzen im Share-Dialog, Auto-Save in Export/Backup UND in der Rail, Tooltips in den Einstellungen, Schrift-Einbetten in der Typography-Karte, Feld-Sichtbarkeit pro World-Group). Eine Sammelregel auf dem Element-Selektor ist hier richtig und nicht zu grob: es gibt keine Checkbox, die absichtlich anders aussehen soll, und jede kuenftige bekommt die Projektfarbe automatisch mit. accent-color faerbt Fuellung und Haken in einem Zug und laesst das native Kaestchen ansonsten unangetastet — bewusst KEIN appearance:none mit nachgebautem Haken: das waere ein zweiter, handgepflegter Zustandsapparat (checked/indeterminate/disabled/focus) fuer einen reinen Farbwunsch. --amber-hi statt --amber, und das ist gemessen, nicht geschaetzt: --amber (#C8A23F) traegt im LIGHT-Theme gegen die Panel-Flaeche (#e6e6e6) nur 1.93:1 — deutlich unter den 3:1, die eine gefuellte Bedienflaeche gegen ihren Untergrund braucht, und schlechter als das native Blau, das ersetzt wird. Genau der Verdacht aus der Freigabe ("koennte im Light Theme zu blass wirken"), er hat sich bestaetigt. --amber-hi ist pro Theme in die jeweils kontrastreichere Richtung definiert (Dark #ddbb5f heller, Light #a8760f dunkler) und misst 3.20:1 im Light- und 7.86:1 im Dark-Theme. Es ist damit der einzige Amber-Token, der in BEIDEN Themes traegt — --amber bleibt unangetastet die Signalfarbe fuer Raender, Text und Badges. */ input[type="checkbox"] { accent-color: var(--amber-hi); } /* ── Button-Basisklassen ────────────────────────────────────────── NEU (2026-08-12, Sitzung A / Etappe 2), KOMPLETT UMGEBAUT (2026-08-13, Nutzer-Vorgabe/SimplifyerX). ══ WAS SICH GEAENDERT HAT UND WARUM ═══════════════════════════ Sitzung A hatte vier ROLLEN (.btn-primary/.btn-secondary/ .btn-icon/.btn-toggle) — abgeleitet aus der Frage "wie wichtig ist diese Aktion?". Das hat sich nicht getragen: die Rolle "Nebenaktion" endete als 2px-Rahmen ohne Fuellung, und der Nutzer-Befund dazu war eindeutig — solche Knoepfe wirken wie Umrandungen, nicht wie Bedienelemente. Ersetzt durch zwei VARIANTEN x drei GROESSEN: .btn default — gefuellter Hintergrund, Rahmen transparent. Die normale Form. .btn.btn-extra extra — 2px Rahmen, kein Hintergrund. Die prominentere Form, bewusst SELTEN. .btn-sm / (—) / .btn-lg small / medium / large. Medium ist der Grundzustand ohne Modifikator. .btn-primary und .btn-secondary sind ERSATZLOS ENTFALLEN: beide hatten nachweislich null Verwendungen im Markup (geprueft in app.js und index.html), es gab also nichts zu migrieren. Die Wichtigkeit einer Aktion traegt jetzt die GROESSE (SAVE ist large), nicht eine eigene Variante — dadurch bleibt "extra" frei fuer genau die eine Aussage "dieser Knopf hier ist der besondere". Aktuell traegt ihn nur IMPORT URL, und das ist der Beweis, dass die Unterscheidung traegt: waere die Haelfte prominent, waere keiner mehr prominent. .btn-icon (Werkzeug) und .btn-toggle (Umschalter) bleiben unberuehrt — das sind keine Textknoepfe, die 49 Werkzeug-Icons sind ausdruecklich Sitzung B. ══ SCHRIFT ════════════════════════════════════════════════════ var(--f-label) statt --f-data, letter-spacing: 0 statt .06em. WICHTIG fuer spaetere Leser: --f-label und --f-data zeigen HEUTE auf dieselbe Familie (JetBrains Mono, siehe :root) — die Umstellung ist visuell also ein No-Op und sieht wie eine sinnlose Aenderung aus. Sie ist trotzdem richtig: ein Button-Text ist ein LABEL ("Speichern"), kein DATENWERT ("1280x720", "3 KB", "2026-08-13"). --f-data traegt die Bedeutung "hier steht ein gemessener Wert". Beide Tokens existieren getrennt, damit genau diese zwei Dinge spaeter unabhaengig voneinander gesetzt werden koennen — sobald das passiert, wuerde jeder Knopf, der noch an --f-data haengt, stillschweigend mitwandern. Bitte NICHT zurueckdrehen, nur weil es heute keinen Unterschied macht. */ .btn { padding: var(--btn-pad-md); background: var(--btn-primary-bg); color: var(--btn-primary-fg); /* 2px transparent statt border: 0 — haelt die Aussenmasse von default und extra identisch, damit ein Wechsel der Variante (oder ein Hover) nichts verschiebt. */ border: 2px solid transparent; border-radius: 0; font-family: var(--f-label); font-size: var(--btn-fs-md); /* NEU (2026-08-13, Nutzer-Vorgabe, vierte Runde): geprueft, welche JetBrains-Mono-Schnitte tatsaechlich ausgeliefert werden (nicht angenommen) — 400/500/600 sind echte Dateien (siehe fonts.css), 700 waere eine Browser-Fälschung von 600 (Deckungstest per Canvas: 600 und 700 legen bitgleich viel Farbe). 500 ist damit der naechste ECHTE Schnitt ueber 400, kein synthetisches Fett. */ font-weight: 500; letter-spacing: 0; text-transform: uppercase; cursor: pointer; /* Der Schatten macht den Knopf ueberhaupt erst als Bedienelement lesbar (Nutzer-Befund). --tile-shadow war bis heute ein TOTES Token — in :root definiert, nirgends verwendet. Genau dafuer war es benannt (kleine, abgesetzte Elemente), und ein totes Token wiederzubeleben ist besser, als einen zweiten Schatten-Stil daneben zu erfinden: SETzz ist eckig und flaechig, --panel-shadow ist die grosse Flaeche (Dialoge, Popover), --tile-shadow die kleine. */ box-shadow: var(--tile-shadow); transition: color .12s, background .12s, border-color .12s; } .btn:hover { background: var(--btn-hover-bg); } .btn-extra { background: transparent; color: var(--ink); border-color: var(--btn-extra-border); /* NACHGEMESSEN (2026-08-13, am gerenderten Knopf auf Staging, nicht vorab entschieden): der Schatten aus .btn WIRKT hier doppelt. Beim gefuellten Knopf liest er sich als Erhebung — es gibt einen sichtbaren Koerper, der ihn wirft. Beim Rahmen-Knopf ist der Koerper durchsichtig; der Schatten sitzt dann als zweite, unscharfe Linie NEBEN der scharfen Rahmenlinie und liest sich wie ein verrutschter doppelter Rand, nicht wie Hoehe. Deshalb hier abgeschaltet: bei dieser Variante traegt der Rahmen die Erkennbarkeit ohnehin allein, dafuer ist er da. */ box-shadow: none; } /* Im Hover fuellt sich der Knopf — ab da gibt es einen Koerper, der einen Schatten werfen kann, also kommt er zurueck. */ .btn-extra:hover { box-shadow: var(--tile-shadow); } /* GEÄNDERT (2026-08-13, Nutzer-Vorgabe): Rahmen ging beim Hover bisher NICHT mit auf die Fuellfarbe — im Dark Theme gemessen 2.08:1 Rahmen-gegen-Fuellung (praktisch unsichtbar), im Light 6.08:1 (klar sichtbar). Zwei Erscheinungsformen fuer denselben Hover-Zustand, je nach Theme, ohne dass das beabsichtigt war. Jetzt zieht der Rahmen bewusst auf --btn-hover-bg, verschmilzt in beiden Themes absichtlich mit der Fuellung statt zufaellig nur in einem. Alternative (Rahmen sichtbar halten) haette eine dritte Erscheinungsform eingefuehrt, die niemand verlangt hat. */ .btn-extra:hover { background: var(--btn-primary-bg); color: var(--btn-primary-fg); border-color: var(--btn-hover-bg); } /* NEU (2026-08-13, Nutzer-Vorgabe): einheitliche Deaktiviert-Behandlung fuer ALLE .btn/.btn-extra-Knoepfe, statt fuenf verschiedener Ad-hoc- Regeln an einzelnen Knoepfen (UPDATE THEME, RESTORE/X, Next set, Duplicate ×2 — je eigene Deckkraft, eigener Cursor, teils ohne Hover-Sperre). Ein deaktivierter Knopf soll wie eine zurueckgenommene Form desselben Knopfes aussehen, nicht wie eine dritte Variante. ZWEI Deckkraftwerte, nicht einer: .btn ist eine gefuellte Flaeche mit viel Kontrastreserve (100% Rahmen/Flaeche gegen Panel: 3.45:1 Light / 3.50:1 Dark), .btn-extra traegt die Erkennbarkeit einzig ueber einen 2px-Rahmen. Bei dem urspruenglich vorgeschlagenen EINEN Wert (40%) faellt der Rahmen auf 1.54:1 / 1.70:1 — praktisch nicht mehr da. Bei 55% bleibt er bei 1.84:1 / 2.04:1, schwaecher als aktiv, aber noch als Rahmen lesbar. .btn bleibt bei 40% (Nutzer-Vorgabe), weil eine gefuellte Flaeche diese Reserve verkraftet. NICHT auf einen gemeinsamen Wert "vereinheitlichen" ohne diese Messung erneut zu pruefen — der Rahmen ist der Grund fuer den Unterschied. */ .btn:disabled { opacity: .4; cursor: not-allowed; } .btn:disabled:hover { background: var(--btn-primary-bg); } .btn-extra:disabled { opacity: .55; cursor: not-allowed; } .btn-extra:disabled:hover { background: transparent; color: var(--ink); border-color: var(--btn-extra-border); box-shadow: none; } .btn-sm { padding: var(--btn-pad-sm); font-size: var(--btn-fs-sm); } .btn-lg { padding: var(--btn-pad-lg); font-size: var(--btn-fs-lg); } /* Destruktive Aktion (das "X" in der Auswahl-Leiste). Bleibt im Ruhezustand ein ganz normaler default-Knopf — das war auch vorher schon so (.lp-assets-bulk-btn-danger unterschied sich ausschliesslich im Hover), ist also keine Verschlechterung. --red ist ein eigener Token, NICHT --amber: die Akzentfarbe bleibt auch hier aussen vor. */ .btn-danger:hover { background: var(--btn-danger-hover-bg); color: var(--red); } .btn-icon { display: flex; align-items: center; justify-content: center; width: var(--btn-size); height: var(--btn-size); background: none; border: 0; color: var(--ink-faint); } .btn-icon:hover { color: var(--amber); } .btn-icon.btn-icon-sm { width: var(--btn-size-sm); height: var(--btn-size-sm); } /* GEÄNDERT (2026-08-13, Sitzung B): 4px 10px / 11px waren HART CODIERT, obwohl die Token daneben stehen — vom neuen check-buttons.php beim ersten Lauf gefunden. Die Klasse traegt heute KEIN Element (0 Treffer im Markup, siehe den Umschalter-Abschnitt in ui-design-system-notes.md), die Umstellung ist damit ohne sichtbare Wirkung — aber genau so faengt Drift an: wer spaeter --btn-fs-sm aendert, uebersieht diese Stelle, und der erste Umschalter, der die Klasse benutzt, faellt aus der Reihe. */ .btn-toggle { padding: var(--btn-pad-sm); background: transparent; border: 0; border-bottom: 2px solid transparent; color: var(--ink-faint); font-family: var(--f-data); font-size: var(--btn-fs-sm); } .btn-toggle:hover { color: var(--ink); } .btn-toggle.active { color: var(--ink-hi); border-bottom-color: var(--amber); } /* NEU: generelle Schrift-Baseline für Buttons in den linken Menü- Panels (Cards/SET Presets/Assets/Search/Tools/Text-to-BOARD/ Export&Backup/Settings/BOARD Settings). Niedrige Spezifität — bereits bestehende, bewusst kompaktere Buttons (z.B. .lp-bs-seg-btn, .lp-bs-save-btn) behalten ihre eigene, spezifischere Font-Regel. */ .left-panel button, .floating-panel button { font-family: var(--f-display); font-size: 14px; font-weight: 500; } /* NACHGEMESSEN UND KORRIGIERT (2026-08-13): die Regel darueber hat die Spezifitaet (0,1,1) und schlaegt damit .btn (0,1,0). Folge, im Browser gemessen, nicht vermutet: JEDER .btn in einem linken oder schwebenden Panel — UPLOAD, IMPORT URL, EXPORT, IMPORT, das X, der BOARD-SETTINGS-SAVE, die Text-to-BOARD-Knoepfe — kam als 14px Rajdhani 500 heraus statt in --f-label und der Token-Groesse. Das ganze Groessen-System waere damit genau dort wirkungslos gewesen, wo es am meisten gebraucht wird. Aufgefallen erst beim Nachmessen im echten Panel: die injizierte Testseite hatte keinen .left-panel- Vorfahren, dort stimmte alles. Bewusst NICHT ueber :where() an der Regel oben geloest, obwohl deren eigener Kommentar "niedrige Spezifitaet" behauptet und die Nachbarregel darunter es so macht: das Absenken auf (0,0,1) wuerde die Rangfolge fuer JEDEN anderen Knopf in diesen Panels umdrehen (Segment-Knoepfe, Typ-Filter, Theme-Zeilen …), also weit ueber diese Runde hinaus. Dieser Zuschnitt hier trifft ausschliesslich .btn. Die eigentliche Spezifitaets-Schieflage der Regel oben bleibt als Befund fuer eine eigene Runde stehen. font-weight: 400 ist kein neuer Wert, sondern der, mit dem .rp-save im rechten Panel (ohne diese Baseline) schon heute rendert — damit sehen alle Knoepfe gleich aus, statt je nach Panel unterschiedlich. */ .left-panel .btn, .floating-panel .btn { font-family: var(--f-label); font-size: var(--btn-fs-md); font-weight: 400; } .left-panel .btn-sm, .floating-panel .btn-sm { font-size: var(--btn-fs-sm); } .left-panel .btn-lg, .floating-panel .btn-lg { font-size: var(--btn-fs-lg); } /* NEU: Normal-/Hover-Hintergrund für Buttons in den linken Menü-Panels (dunkel Grau/Schwarz bei Dark, hell Grau/Weiß bei Light). :where() hält die Spezifität bei genau einem Element-Selektor, damit bereits spezifisch gestylte Buttons (Segment-Buttons, Icon-Buttons, Save- Button etc.) diese Baseline weiterhin unverändert überschreiben. */ :where(.left-panel, .floating-panel) button { background: transparent; transition: background .12s; } :where(.left-panel, .floating-panel) button:hover { background: #000; } :where([data-theme="light"]) :where(.left-panel, .floating-panel) button:hover { background: #fff; } a { color: inherit; text-decoration: none; } ul { list-style: none; } img, svg { display: block; } html, body { height: 100%; } body { background: var(--bg); color: var(--ink); font-family: var(--f-label); font-size: 13px; line-height: 1.45; height: 100vh; overflow: hidden; } /* NEU (2026-07, Nutzer-Rückmeldung): 100% Deckkraft wirkte zu hart. color-mix() liest --amber LIVE — funktioniert also automatisch mit jeder gewählten Accent-Farbe (Standard oder per applyWorldAccent() überschrieben), ohne dass diese Regel je wieder angefasst werden muss. Erste Zeile ist der Fallback für Browser ohne color-mix() (ungültige Deklaration wird ignoriert, die gültige davor bleibt bestehen) — 20% eines mittleren Amber-Tons als fester Näherungswert. */ ::selection { background: rgba(200, 162, 63, .2); background: color-mix(in srgb, var(--amber) 20%, transparent); color: #000; } /* NEU (2026-07): dezente Textauswahl-Farbe speziell in Eingabefeldern — statt der globalen Amber-Akzentfarbe (die bleibt für den Rest der Anwendung, z.B. Board-Text, unverändert bestehen). */ input::selection, textarea::selection { background: var(--line); color: var(--ink); } /* ── App grid: 3-zone layout ──────────────────────────────── rail (fixed 48px) | left-panel (0→220px) | main (flex) | right-panel (0→240px) All zones are flex children on the root .app row. ─────── */ .app { display: flex; height: 100vh; overflow: hidden; } /* ── Left Rail ──────────────────────────────────────────── */ .left-rail { width: var(--rail-w); flex-shrink: 0; background: var(--bg); border-right: 1px solid var(--line-soft); display: flex; flex-direction: column; align-items: center; padding: 8px 0; gap: 2px; z-index: 30; } /* NEU (2026-08-04): Abwurfzone beim Ziehen eines schwebenden Panels zurück auf die Rail — Gegenstück zum Titelzeilen-Drag. Gleiche Sprache wie .upload-drop-ready (Amber-Innenrahmen), zusätzlich ein Hintergrund-Tönung, da die Rail nur 48px breit ist und ein reiner Rahmen dort leicht übersehen würde. */ .left-rail.left-rail-dock-target { background: var(--amber-dim, rgba(200,163,74,.14)); outline: 2px solid var(--amber); outline-offset: -2px; } /* GEÄNDERT (2026-08-17, Branding-Release logo-04): das Bild schrumpft von 36px auf 26px (Nutzer-Vorgabe), die Trefferfläche soll das nicht mitmachen. .rail-logo hatte vorher KEIN eigenes Padding/Breite — die Box war exakt so breit wie ihr breitestes Kind (das Bild, 36px, gemessen). Padding statt fester Breite hätte hier ueberschossen: das Label ("Alpha", ~30px) ist bereits breiter als das neue 26px-Bild und waere selbst zum breitesten Kind geworden, +10px Padding haette dann ~40px ergeben statt 36px (auf Staging gemessen, korrigiert). Feste Breite umgeht das: unabhaengig davon, welches Kind gerade breiter ist, bleibt die Box exakt 36px. */ .rail-logo { margin-bottom: 10px; width: 36px; display: flex; flex-direction: column; align-items: center; gap: 3px; } /* NEU (2026-08-03): das Logo ist der Weg zurueck ins Dashboard — der Zeiger sagt das an, solange es einen Weg zurueck gibt. Im Dashboard selbst (data-app ohne .board-open) bleibt es ein Bild. */ .app.board-open .rail-logo { cursor: pointer; } .rail-logo-img { width: 26px; height: 26px; object-fit: contain; display: block; } .rail-logo-label { display: block; opacity: 0; font-family: var(--f-display); font-size: 13px; letter-spacing: 0; color: inherit; text-transform: none; } :root[data-theme="light"] .rail-logo-img { filter: invert(1); } /* Zurück-zum-Dashboard-Pfeil (NEU 2026-07): sitzt unterhalb des Logos, mit etwas Abstand — nur sichtbar, solange ein Board geöffnet ist. */ .rail-back-btn { width: 32px; height: 32px; margin: 6px auto 0; display: grid; place-items: center; border: 0; border-radius: 0; background: transparent; color: var(--ink-faint); cursor: pointer; transition: color .15s, background .15s; } .rail-back-btn svg { width: 16px; height: 16px; } .rail-back-btn:hover { color: var(--amber); background: var(--panel-2); } /* NEU: visibility statt display:none — Button bleibt im Layout erhalten, damit die Rail-Nav-Icons darunter nicht nach oben rutschen, sobald der Zurück-Pfeil bei offenem Menü-Panel unsichtbar wird (siehe updateRailBackBtnVisibility(), app.js). Nicht klickbar währenddessen. */ .rail-back-btn.rail-back-btn-invisible { visibility: hidden; pointer-events: none; } .rail-nav { display: flex; flex-direction: column; align-items: center; gap: 2px; flex: 1; margin-top: 1.2rem; } .rail-bottom { display: flex; flex-direction: column; align-items: center; gap: 6px; padding-bottom: 4px; } .rail-sep { width: 24px; height: 1px; background: var(--line-soft); margin: 4px 0; } .rail-btn { width: 38px; height: 38px; /* GEÄNDERT (2026-08-12): war 32px, +6px Nutzer-Vorgabe */ display: grid; place-items: center; border: 0; border-radius: 0; background: transparent; color: var(--ink-faint); cursor: pointer; transition: color .15s, background .15s; } /* NEU (2026-08-19, "Detail-Panel: fünf Nachbesserungen", Punkt 1): .rail-btn ist KEINE reine Rail-Klasse — dieselbe Klasse trägt auch die fünf Icons der Send-Asset-Zeile im Detail-Panel (rp-send-asset-find/ -icons, siehe openRightPanelForUpload() in app.js: Show/Locate/ Open-Tab/Crop/More). Eine Änderung auf .rail-btn selbst hätte also beide Stellen getroffen. Gezielt auf .left-rail gescopt (der Wrapper