/* ============================================================================ Gestaltungs-Token der Anwendung - 2026-08-21 WOFUER: Eine einzige Stelle, an der Flaechen-, Linien-, Text- und Akzentfarben stehen. Ohne sie ist ein dunkles Erscheinungsbild nicht nachruestbar: die Anwendung trug am 21.08.2026 rund 97 fest verdrahtete weisse Hintergruende, 72-mal die Textfarbe #6c757d, 66-mal die Linienfarbe #dee2e6 und 80-mal die Flaeche #f8f9fa - verteilt ueber Dutzende Dateien. Genau deshalb blieb der Dark-Mode-Schalter bis zum 25.08.2026 ausgeblendet. Seit dem 25.08.2026 ist er scharf (SettingsUserPage -> "Farbschema"); die verbliebenen fest verdrahteten Farben sind damit im Betrieb sichtbar statt nur zaehlbar. WIE DIE WERTE ZUSTANDE KAMEN: nicht erfunden, sondern ausgezaehlt. Jeder Token ist der in der Anwendung am haeufigsten vorkommende Wert seiner Rolle; die Zahl in Klammern ist die gemessene Haeufigkeit. Dadurch ist das Umstellen einer Datei auf Token in aller Regel ein reines Ersetzen ohne Farbwechsel. WARUM HIER GAR NICHTS AUS MUD GESPIEGELT WIRD (urspruenglich anders geplant, zweimal korrigiert am 21.08.2026): Erstens weichen die Werte ab. Gemessen im hellen Erscheinungsbild: --mud-palette-surface rgb(255,255,255) = #fff identisch --mud-palette-background-gray #f5f5f5 vs #f8f9fa abweichend --mud-palette-lines-default rgba(0,0,0,0.118) vs #dee2e6 abweichend --mud-palette-text-secondary rgba(0,0,0,0.537) vs #6c757d abweichend --mud-palette-primary rgb(89,74,226) vs #0d6efd abweichend Ein pauschales Spiegeln haette die halbe Anwendung leicht umgefaerbt. Zweitens - und das ist der eigentliche Grund - macht Spiegeln die Token vom Zustand einer FREMDBIBLIOTHEK abhaengig. --app-surface hing zwischenzeitlich an --mud-palette-surface. Beim Test mit "app-dark" blieben daraufhin alle Kartenflaechen weiss, waehrend Linien und Textfarben schon dunkel waren: die Klasse sagt Mud nichts, also lieferte Mud weiter Weiss. Eine Token-Schicht, die nur zusammen mit dem Theme einer fremden Komponentenbibliothek funktioniert, ist keine. Alle Werte stehen deshalb ausdruecklich hier. STAND 24.08.2026: Es gibt keine Arbeitsteilung mehr - MudBlazor ist raus. Die rund 105 Stellen, die noch var(--mud-palette-*) lasen, sind auf die Token hier umgestellt (Rolle fuer Rolle: text-secondary -> --app-text-muted, lines-default -> --app-line, surface -> --app-surface, background-gray -> --app-surface-subtle, action-default-hover -> --app-surface-hover, *-text -> --app-text-on-accent, primary und info -> --app-accent, secondary -> --app-accent-alt). SICHTBARE FOLGE: Wo vorher Muds Violett (#594AE2) stand, steht jetzt das Blau der Anwendung (#0d6efd) - Ueberschriften auf /about und der Startseite, Akzente im Revisionsvergleich und im Planungs-Dashboard. Das war der Zweck: die handgeschriebenen Bereiche benutzen durchgaengig EINE Akzentfarbe. Die dunklen Werte unten stammen noch aus der Zeit, als sie zu Muds dunkler Flaeche (#373740) passen mussten. ABSICHTLICH KEINE ABSTANDS-TOKEN: Bootstrap (p-*, m-*, gap-*) und MudBlazor (pa-*, ma-*) bringen beide bereits ein vollstaendiges Abstandssystem mit. Ein drittes waere genau der Wildwuchs, den wir gerade abbauen. Abstaende bitte weiter ueber die Utility-Klassen. BENUTZUNG: var(--app-surface) statt #fff, var(--app-text-muted) statt #6c757d usw. Immer MIT Ersatzwert schreiben - var(--app-line, #dee2e6) - damit ein Tippfehler im Tokennamen nicht still zu einer durchsichtigen Flaeche fuehrt. Genau dieser Fehler ist uns am 21.08.2026 mit --mud-palette-background-grey passiert: den Token gibt es nicht, und ohne Ersatzwert standen die Kacheln auf /about unsichtbar da. ============================================================================ */ /* 2026-08-25, NACHTRAG ZUM NACHTRAG: der Selektor lautet ':root, [data-bs-theme="light"]' und nicht nur ':root' - genau wie bei Bootstrap. WARUM, im laufenden Programm gefunden: Custom Properties VERERBEN. Steht am das dunkle Schema, dann gelten die dunklen Werte auch in einem Ausschnitt, der ausdruecklich data-bs-theme="light" traegt - denn dort setzt sie niemand zurueck. Die helle Vorschau in der Farbschema-Auswahl war deshalb dunkel, sobald die Anwendung dunkel stand. Der zweite Selektor ist die Rueckstellung. */ :root, [data-bs-theme="light"] { /* --- Flaechen ------------------------------------------------------------------- */ /* Karten, Dialoge, Tabellenhintergrund. (97x) */ --app-surface: #ffffff; /* Leicht abgesetzt: Kopfzeilen, Streifen, ruhige Bloecke. (80x) */ --app-surface-subtle: #f8f9fa; /* Staerker abgesetzt: Suchfelder, Seitenleisten-Kopf. (22x) */ --app-surface-sunken: #f0f2f5; /* Zeile unter dem Mauszeiger, aktiver Listeneintrag. (18x) */ --app-surface-hover: #e9ecef; /* Gesperrte Flaeche (AButton :disabled). 2026-08-25 ergaenzt: bewusst DUNKLER als --app-surface-hover, sonst waere ein gesperrter Knopf vom ueberfahrenen nicht zu unterscheiden. Deshalb ein eigener Token und kein Zusammenlegen. */ --app-surface-disabled: #d1d5db; /* Flaeche der linken Navigation. 2026-08-25 ergaenzt, als der Dunkelmodus scharf wurde: #f7f7f7 stand an DREI Stellen fest verdrahtet (MainLayout.razor.css .app-drawer-panel, NavMenuLeft als Inline-Stil, NavMenuLeft_COV2 als Inline-Stil) und liess die Navigation auf JEDER Seite als weissen Riegel stehen. Bewusst ein eigener Token und nicht --app-surface-subtle: der Wert ist #f7f7f7, nicht #f8f9fa - Zusammenlegen waere eine Farbaenderung, kein Aufraeumen. */ --app-nav-surface: var(--app-nav-surface-override, #f7f7f7); /* ============================================================================ DIE -override-EBENE - und warum es sie geben MUSS (26.08.2026, im laufenden Programm gemessen, nachdem der erste Versuch ohne sie danebenging) Drei Token werden von aussen umgesetzt: von einem Corporate Design (BrandingCss) und von der persoenlichen Farbwahl (applySurfaceColors in app.js). Beide setzten zunaechst den Token SELBST - das Ergebnis war an der Anwendung richtig und in der Farbschema-Vorschau falsch. DER GRUND: Die Bloecke hier heissen ":root, [data-bs-theme=light]" bzw. "[data-bs-theme=dark]" - absichtlich, damit ein Ausschnitt mit eigenem Attribut sein eigenes Schema bekommt (die Vorschau-Kaertchen im ColorSchemeDialog leben davon). Genau das schlaegt aber zurueck: ein Kaertchen mit data-bs-theme="light" bekommt den Token hier NEU gesetzt, und eine eigene Deklaration am Element schlaegt jeden geerbten Wert - auch einen, der als Inline-Eigenschaft am steht. Gemessen: Kopfleiste der Anwendung gruen, Kopfleiste im hellen Vorschaubild grau. DIE LOESUNG: Nicht den Token umsetzen, sondern eine Ebene darunter. --*-override wird nirgends in dieser Datei definiert, kann also von keinem Schema-Block zurueckgesetzt werden; es erbt vom in JEDEN Ausschnitt hinein. Ist nichts gesetzt, greift der Ersatzwert - dann steht hier exakt das, was vorher dastand. WER SETZT: BrandingCss (Marke, im :root-Block) oder applySurfaceColors (persoenlich, inline am ). NIE beide - die Marke sticht, siehe BrandingCss.OwnsSurfaces. ============================================================================ */ /* ZWEI TOKEN, DIE HIER ABSICHTLICH FEHLEN: --app-nav-text und --app-nav-hover. Sie werden NUR gesetzt, wenn ein Benutzer die Navigation selbst eingefaerbt hat (2026-08-26, applySurfaceColors in app.js, als Eigenschaft am -Element). Ohne eine solche Wahl bleiben sie ungesetzt, und die Regeln, die sie lesen, greifen auf ihre Ersatzwerte zurueck - also auf genau das bisherige Verhalten. Haetten sie hier einen Wert, waere aus einer Wahlmoeglichkeit eine Farbaenderung fuer alle geworden. Wo sie gelesen werden, steht in MainLayout.razor.css (Block "app-nav-personal"). */ /* Flaeche und Schrift der Kopfleiste. 2026-08-25 ergaenzt, als die persoenliche Farbwahl entfiel (UserSetting.AppBarColor) - seit dem 26.08.2026 gibt es sie wieder, aber ueber diese Token statt ueber Inline-Stile am Element (UserSetting. PersonalAppBarColor). Was hier steht, ist damit die VORGABE, nicht mehr die einzige Moeglichkeit. WARUM NICHT EINFACH --app-accent: Die Kopfleiste war nie in der Akzentfarbe, sondern in einem neutralen Grau. Sie jetzt blau zu machen waere eine Farbaenderung fuer jeden Bestandsnutzer - und zwar an der auffaelligsten Stelle der Anwendung. Der Wert hier ist deshalb exakt der bisherige Vorgabewert (UserSetting.AppBarDefaultColor). WARUM IN BEIDEN SCHEMATA GLEICH: Das Grau traegt weisse Schrift und funktioniert hell wie dunkel. Es gehoert zur Kopfleiste, nicht zum Schema - wie --app-text-on-accent. Ist ein Corporate Design eingerichtet, ueberschreibt BrandingCss beide Werte mit der Hausfarbe und der dazu BERECHNETEN Schriftfarbe. */ --app-appbar-surface: var(--app-appbar-surface-override, #5e5e5e); --app-appbar-text: var(--app-appbar-text-override, #ffffff); /* --- Linien -------------------------------------------------------------------- */ --app-line: #dee2e6; /* Standardtrenner (49x) */ --app-line-subtle: #e9ecef; /* Zurueckhaltender Trenner innerhalb einer Flaeche (28x) */ --app-line-strong: #cccccc; /* Deutlicher Rahmen, Eingabefeldrand (25x) */ /* --- Text ---------------------------------------------------------------------- */ --app-text: #212529; /* Fliesstext (20x) */ --app-text-secondary: #495057; /* Ueberschriften kleiner Bloecke, Beschriftungen (21x) */ --app-text-muted: #6c757d; /* Nebeninformation, Zeitstempel (58x + 39x #6b7280) */ --app-text-disabled: #adb5bd; /* Gesperrt, Platzhalter (14x) */ --app-text-on-accent: #ffffff; /* Schrift auf farbigem Grund (91x) */ /* Das Gegenstueck: DUNKLE Schrift auf einer HELLEN, festen Farbflaeche - Bernstein, Gelb, helles Gruen. 2026-08-25 ergaenzt, nachdem im laufenden Programm auffiel, dass die Zusammenlegung color:#212529 auch dort zu var(--app-text) gemacht hatte, wo daneben background:#ffc107 steht: die Flaeche bleibt Bernstein, die Schrift kippte mit - gemessen helles Grau rgb(222,226,230) auf rgb(255,193,7). Wie --app-text-on-accent gehoert dieser Token zur FLAECHE, nicht zum Schema, und steht deshalb im dunklen Block bewusst NICHT noch einmal. */ --app-text-on-light: #212529; /* Rueckstellung der Nur-im-Dunkeln-Token. "initial" macht eine Custom Property wieder UNGESETZT - var(--x, ersatz) greift dann auf den Ersatzwert, also den Originalton. Gebraucht wird das nur bei Verschachtelung (helle Vorschau unter dunkler Wurzel); ohne diese Zeilen erbte der helle Ausschnitt die dunklen Toenungen. */ --app-tint-red: initial; --app-tint-amber: initial; --app-tint-green: initial; --app-tint-teal: initial; --app-tint-blue: initial; --app-tint-purple: initial; --app-ink-red: initial; --app-ink-amber: initial; --app-ink-green: initial; --app-ink-teal: initial; --app-ink-blue: initial; --app-ink-purple: initial; /* --- Akzente ------------------------------------------------------------------- */ /* Bewusst die BOOTSTRAP-Werte, nicht Muds: die handgeschriebenen Bereiche der Anwendung benutzen durchgaengig diese. Mud-Komponenten bleiben bei ihrer eigenen Palette - das ist gewollt, sonst muesste man beide Systeme angleichen. */ --app-accent: #0d6efd; --app-danger: #dc3545; --app-success: #28a745; --app-warning: #fd7e14; /* Zweite Akzentfarbe. 2026-08-24 ergaenzt: sie stammt aus MudBlazors Sekundaerfarbe und wird an genau DREI Stellen gebraucht - der Zeitstrahl-Verlauf und die Versions-Abzeichen im Revisionsvergleich. Beim Ausbau von MudBlazor uebernommen, statt die Ansicht umzufaerben. Wer sie sonst nirgends braucht, laesst sie in Ruhe. */ --app-accent-alt: #ff4081; /* Flaeche fuer Warnhinweise (Bootstrap-Gelb). 2026-08-22 ergaenzt fuer die Platzhalter-Kaesten der Datenschutzseite. */ --app-warning-surface: #fff3cd; /* AKZENTFARBE ALS TEXT - 25.08.2026. Die vier Token oben sind FLAECHENfarben (Knopf, Abzeichen, Balken) und bleiben im dunklen Schema unveraendert. Wer eine Akzentfarbe als SCHRIFT oder Symbol setzt, nimmt diese hier: nur sie kippen mit dem Schema, und nur so bleibt farbiger Text auf dunklem Grund lesbar (#0d6efd auf #212529 waeren 3,7:1). Im hellen Schema sind es dieselben Farben wie oben - mit zwei Ausnahmen, die als Text auf Weiss zu schwach waeren: Gruen (#28a745 = 3,1:1) und Orange (#fd7e14 = 2,4:1) weichen auf Bootstraps dunklere Textvarianten aus. */ --app-accent-text: #0d6efd; --app-danger-text: #dc3545; --app-success-text: #198754; --app-warning-text: #997404; /* --- Cockpit-Stufen ------------------------------------------------------------ */ /* Beschaffungs- und Fertigungs-Cockpit teilen sich BEWUSST dieselbe Stufenoptik ("damit Einkauf und Fertigung dieselbe Sprache sprechen", siehe Kopf der beiden .razor.css). Die drei Stufen sind der Grund, warum diese Toene NICHT auf --app-surface-subtle zusammengelegt werden duerfen: Stufe 2 ist zufaellig #f8f9fa, aber sie ist Teil einer Leiter. Legt man nur sie um, bricht im Dunkeln die Reihenfolge und die Stufen sind nicht mehr unterscheidbar. */ --cockpit-row-1: #f1f3f5; /* Kopfzeile je Bauteil/Teil - hebt sich am staerksten ab */ --cockpit-row-2: #f8f9fa; /* Mengen-/Zwischenzeile */ --cockpit-row-3: #fbfcfd; /* Unterzeilen (Schaetzung, Lieferanten, Dienstleister) */ --cockpit-section: #e9f5f4; /* Abschnittsueberschrift der Preis-/Kostenmaske */ --cockpit-chosen: #e7f5ec; /* nominierte bzw. gewaehlte Bezugsquelle */ /* --- Schrift ------------------------------------------------------------------- */ /* WARUM ES DIESEN TOKEN GIBT (22.08.2026): Die Anwendung hatte drei konkurrierende Angaben - 'Helvetica Neue' in app.css, Muds Roboto-Stack und viermal fest 'Segoe UI'. Gemessen wurde daraus: WEDER Helvetica Neue NOCH Roboto sind auf einem Standard-Windows installiert, die Anwendung lief also faktisch auf Arial (ueber den Helvetica-Alias), waehrend die vier Segoe-Seiten sichtbar anders aussahen. Die Vorgabe ist die SYSTEMSCHRIFT: unter Windows Segoe UI, auf dem Mac San Francisco, auf Android Roboto. Kein Download, sofort da, ueberall nativ. UMSCHALTEN: Der Benutzer kann in den Einstellungen eine mitgelieferte Schrift waehlen. Dann traegt die Klasse .font-inter bzw. .font-source-sans (gesetzt aus MainLayout, genau wie die Farbe der Kopfleiste), und nur --app-font aendert sich. Weil ALLES ueber diesen Token laeuft - auch MudBlazors Typografie - zieht das die gesamte Oberflaeche mit. */ /* CJK-ERSATZ AM ENDE - 07.09.2026: keine der lateinischen Schriften oben hat ein einziges chinesisches Zeichen. Ohne diese vier Familien faellt CJK-Text bis zur generischen sans-serif durch und landet bei dem, was der Browser gerade greift - je nach Rechner eine andere Schrift, teils eine Serifenschrift. Weil der Browser ZEICHENWEISE ersetzt, holt er lateinische Buchstaben weiterhin aus Segoe UI & Co. und nur die Han-Zeichen von hier; die Reihenfolge deckt Windows, macOS/iOS und Linux/Android ab. Alle vier sind auf dem jeweiligen System vorhanden, es wird also NICHTS ausgeliefert - eine CJK-Schrift selbst mitzugeben waere zweistellig MB und steht wegen der Autark-Regel ohnehin nicht zur Wahl. Aufgenommen sind die Familien fuer VEREINFACHTES Chinesisch; traditionelles braeuchte eigene ("Microsoft JhengHei", "PingFang TC"). Gilt vorsorglich, auch solange es die Sprache noch nicht gibt: die Zeile kostet nichts und ein falsch gesetzter Name faellt sonst erst dem ersten chinesischen Benutzer auf. */ --app-font: system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", "Noto Sans CJK SC", sans-serif; /* Festbreitenschrift fuer Zahlenkolonnen, Zeitanzeigen und Diff-Ansichten. Vorher gab es dafuer VIER verschiedene Schreibweisen ('Courier New', bloss monospace, und zweimal einen ui-monospace-Stack). ui-monospace zuerst, weil das auf jedem System die dafuer vorgesehene Schrift trifft (Windows: Cascadia/Consolas, Mac: SF Mono). */ --app-font-mono: ui-monospace, "Cascadia Mono", "Segoe UI Mono", "Roboto Mono", Menlo, Monaco, Consolas, "Courier New", monospace; /* --- Schriftgroessen: die Skala - 03.09.2026 ------------------------------------- WARUM: Ausgezaehlt gab es in den Stilblaettern 45 verschiedene rem-Werte - allein zwischen 0,62 und 0,78 rem zehn Abstufungen, also in einem Bereich, in dem das Auge zwei unterscheiden kann. Nebeneinanderliegende Bereiche wirkten dadurch unruhig, ohne dass jemand haette sagen koennen, woran es liegt: es gab keinen sichtbaren Unterschied, nur einen messbaren. Und 219 Vorkommen lagen unter 12px - zu klein fuer Text, der acht Stunden am Tag gelesen wird. DIE SKALA: sieben Stufen, 12 / 14 / 16 / 18 / 20 / 24 / 32 px. Das kleinste ist die UNTERGRENZE fuer alles, was Text ist: Beschriftungen, Zeitstempel, Nebeninformation. Wer kleiner will, will in Wahrheit gedaempfter - dafuer gibt es --app-text-muted. Ausgenommen sind nur die grossen Kennzahlen der Kacheln (3rem und mehr), die keine Skalenstufe sind, sondern Anzeige. WIE UMGESTELLT WURDE: jeder bestehende Wert auf die naechstgelegene Stufe; die Untergrenze zieht alles darunter auf 12px hoch. Nirgends aendert sich mehr als gut ein Punkt. Neue Stilblaetter nehmen die Stufe, nicht die Zahl. WARUM --app-type-* UND NICHT --app-text-* ODER --app-font-*: --app-text ist die TEXTFARBE, --app-font die SCHRIFTFAMILIE. Ein dritter Begriff, damit sich niemand vertut. */ --app-type-xs: 0.75rem; /* 12px - Beschriftungen, Zeitstempel, Etiketten */ --app-type-sm: 0.875rem; /* 14px - Tabellen, Formulare, dichter Fliesstext */ --app-type-md: 1rem; /* 16px - Fliesstext */ --app-type-lg: 1.125rem; /* 18px - Zwischenueberschriften */ --app-type-xl: 1.25rem; /* 20px - Seitentitel klein */ --app-type-2xl: 1.5rem; /* 24px - Seitentitel */ --app-type-3xl: 2rem; /* 32px - Kennzahlen, grosse Ueberschriften */ /* --- Feldhoehe ----------------------------------------------------------------- */ /* 12.09.2026: Die Hoehe eines kleinen Eingabefeldes - EIN Mass fuer Felder UND Knoepfe. WOFUER: Ein Knopf neben einem Feld (die Lupe an der Einheit, am Land, am Kursverlauf) stand vorher 3px hoeher als das Feld daneben. Das Paar las sich wie zwei Teile aus verschiedenen Masken. Seitdem holen sich .abutton und die handgebauten Zwillinge in der Kopfleiste ihre Hoehe hier. DIE RECHNUNG ist Bootstraps eigene fuer .form-select-sm / .form-control-sm: Zeilenhoehe 1.5 x Schriftgrad 0.875rem + je 0.25rem Innenabstand + je 1px Rahmen = 31px. Ausgeschrieben statt als 31px, damit sie mitwaechst, wenn jemand die Grundschrift des Browsers groesser stellt - dort skaliert rem, px nicht. */ --app-field-height: calc(1.5 * 0.875rem + 0.5rem + 2px); /* --- Radien -------------------------------------------------------------------- */ --app-radius-sm: 4px; /* Knoepfe, Etiketten (98x) */ --app-radius-md: 8px; /* Karten, Dialoge (71x) */ --app-radius-lg: 12px; /* Grosse Kacheln (24x) */ /* --- Schatten ------------------------------------------------------------------ */ --app-shadow-sm: 0 1px 3px rgba(0, 0, 0, 0.1); --app-shadow-md: 0 2px 8px rgba(0, 0, 0, 0.1); --app-shadow-lg: 0 0.5rem 1rem rgba(0, 0, 0, 0.15); } /* ============================================================================ Dunkles Erscheinungsbild - SEIT 25.08.2026 SCHARF GESCHALTET WIRD AN data-bs-theme="dark" AM -ELEMENT, nicht an einer eigenen Klasse. Das ist der Kern der Sache und war bis zum 25.08.2026 anders geplant: Bootstrap 5.3 (ausgeliefert wird 5.3.3) bringt mit data-bs-theme einen eigenen, vollstaendigen Farbschema-Schalter mit. Er kippt Karten, Tabellen, Formulare, Dropdowns, Ausklappmenues, Rahmen und Textfarben - also alles, was Bootstrap malt, und das ist der groessere Teil dieser Oberflaeche. Haengt der dunkle Block hier an einer EIGENEN Klasse (frueher "app-dark"), dann wird nur das Selbstgeschriebene dunkel und der ganze Bootstrap-Anteil bleibt hell. Genau dieser Fehler ist mit MudBlazor schon einmal passiert (siehe oben, Irrweg 2). Ein Attribut, ein Umschalter, beide Systeme. Zusaetzlich setzt Bootstrap unter diesem Attribut "color-scheme: dark". Damit ziehen auch die Dinge mit, an die kein Stylesheet herankommt: Rollbalken, native Auswahlfelder, Datumswaehler, Autovervollstaendigung. WOHER DIE WERTE STAMMEN (25.08.2026 neu gegruendet): aus Bootstraps eigener dunkler Palette. Die alten Werte hier waren auf MudBlazors dunkle Flaeche (#373740) abgestimmt - MudBlazor ist seit dem 24.08.2026 raus, und #373740 haette neben Bootstraps Karten (#212529) als zweite, fremde Flaeche gestanden. Die Zuordnung ist rollenweise dieselbe wie im Hellen, wo die Token ohnehin Bootstraps Werte SIND (ausgezaehlt, nicht abgeschrieben): --app-surface #ffffff -> #212529 (--bs-body-bg, zugleich --bs-card-bg) --app-surface-subtle #f8f9fa -> #2b3035 (--bs-tertiary-bg) --app-surface-sunken #f0f2f5 -> #343a40 (--bs-secondary-bg) --app-line #dee2e6 -> #495057 (--bs-border-color) --app-text #212529 -> #dee2e6 (--bs-body-color) DIE LEITER DREHT SICH UM, DIE ORDNUNG BLEIBT: im Hellen wird jede weitere Stufe dunkler (#ffffff -> #f8f9fa -> #f0f2f5), im Dunklen heller (#212529 -> #2b3035 -> #343a40). Was erhalten bleibt, ist der ABSTAND zur Grundflaeche - und darauf beruht die Stufenoptik der Cockpits weiter unten. IM LAUFENDEN PROGRAMM GEMESSEN (25.08.2026), ABER NICHT ANGESEHEN. Nachgemessen sind die Werte selbst (--app-surface #ffffff -> #212529, --app-line -> #495057, --app-text -> #dee2e6, --app-accent-text -> #6ea8fe bei unveraendertem --app-accent) und das Verhalten der Oberflaeche darauf. Ein optisches Urteil ist das NICHT - die Browser-Ansicht liefert in dieser Umgebung keine Bilder. Was beim Hinsehen auffaellt, gehoert HIER korrigiert, nicht in der einzelnen Datei. ZUM PRUEFEN OHNE ANMELDUNG genuegt in der Browserkonsole: document.documentElement.dataset.bsTheme = 'dark' Dann sieht man sofort, welche Stellen noch fest verdrahtet sind. Stand 25.08.2026 sind das noch rund 1.600 Hex-Werte in 117 CSS-Dateien und 779 in .razor-Dateien; sie rollenweise auf Token zu ziehen ist die eigentliche Arbeit und laeuft weiter. ============================================================================ */ /* 2026-08-25, NACHTRAG: Der Selektor ist bewusst [data-bs-theme="dark"] und NICHT :root[data-bs-theme="dark"]. WARUM: Genau so macht es Bootstrap selbst - dort steht [data-bs-theme=dark], nicht an :root gebunden. Damit darf das Attribut auch an einem BELIEBIGEN Element stehen und faerbt nur dessen Teilbaum. Gebraucht wird das von der Theme-Vorschau: sie muss beide Schemata NEBENEINANDER zeigen, und das geht nur, wenn ein Ausschnitt der Seite dunkel sein kann, waehrend der Rest hell bleibt. Die Alternative waere gewesen, die dunklen Werte in der Vorschau noch einmal hinzuschreiben - also genau die Doppelung, die diese Datei abschafft. Am gewohnten Verhalten aendert sich nichts: gesetzt wird das Attribut weiterhin nur an . Die Spezifitaet sinkt von (0,2,0) auf (0,1,0) und ist damit gleichauf mit dem :root-Block oben - entschieden wird ueber die Reihenfolge, und dieser Block steht danach. */ [data-bs-theme="dark"] { /* --- Flaechen: die Leiter dreht sich um (siehe Kopf) ---------------------------- */ --app-surface: #212529; --app-surface-subtle: #2b3035; --app-surface-sunken: #343a40; --app-surface-hover: #3a4046; --app-surface-disabled: #3f464d; /* Die Navigation bleibt eine Stufe ueber der Grundflaeche - im Hellen heller als der Inhalt waere sie nicht (sie ist dort dunkler), im Dunklen heller. Gleiche Rolle: abgesetzt, aber ruhig. */ --app-nav-surface: var(--app-nav-surface-override, #2b3035); /* --- Linien -------------------------------------------------------------------- */ /* Bewusst SOLIDE Werte statt rgba(255,255,255,...) wie frueher: halbdurchsichtige Linien addieren sich, wo Rahmen aneinanderstossen (Tabellenzellen, verschachtelte Karten), und werden dort sichtbar kraeftiger als anderswo. */ --app-line: #495057; --app-line-subtle: #343a40; --app-line-strong: #6c757d; /* --- Text ---------------------------------------------------------------------- */ --app-text: #dee2e6; --app-text-secondary: #adb5bd; --app-text-muted: #8f979e; /* 5,3:1 auf --app-surface - AA fuer Fliesstext */ --app-text-disabled: #6c757d; --app-text-on-accent: #ffffff; /* --- Akzente ------------------------------------------------------------------- */ /* HIER STEHT ABSICHTLICH KEIN --app-accent, --app-danger, --app-success, --app-warning. Die vier sind FLAECHENfarben (Knopf, Abzeichen, Balken) und bleiben im Dunklen exakt gleich - genauso haelt es Bootstrap mit .btn-primary & Co. Wuerde man sie aufhellen, wuerde die weisse Schrift darauf unlesbar. Fuer Akzentfarbe als TEXT oder Symbol auf dunklem Grund gibt es die vier Token unten: #0d6efd auf #212529 ergaebe nur 3,7:1, #6ea8fe dagegen 7,4:1. Die Werte sind Bootstraps eigene *-text-emphasis-Werte des dunklen Schemas. */ --app-accent-text: #6ea8fe; --app-danger-text: #ea868f; --app-success-text: #75b798; --app-warning-text: #ffda6a; --app-accent-alt: #ff79ab; --app-warning-surface: #332701; /* --bs-warning-bg-subtle des dunklen Schemas */ /* --- Toenungen und farbige Schrift: NUR HIER DEFINIERT ------------------------- */ /* ACHTUNG, DAS MUSTER IST HIER UMGEDREHT. Diese zwoelf Token haben BEWUSST keinen :root-Wert. Im hellen Schema sind sie undefiniert, also greift an der Aufrufstelle der Ersatzwert - und der ist dort der urspruengliche Literalwert. Das helle Schema bleibt dadurch BYTE-IDENTISCH, das dunkle bekommt einen Ton derselben Familie. WARUM NICHT WIE BEI DEN GRAUTOENEN ZUSAMMENLEGEN (25.08.2026 entschieden): die Grautoene waren historische Dubletten desselben gemeinten Tons - #f2f2f2 statt #f0f2f5, nicht wahrnehmbar verschieden, Zusammenlegen ist dort reines Aufraeumen. Diese hier sind absichtlich verschiedene Toenungen, und jede traegt einen Hinweis: #fdf3f4 ist das ueberfaellige Termin-Pill, #d9fdd3 die eigene Nachricht im Messenger, #fff3e0 eine Warnflaeche. Auf EINEN Ton gelegt verloeren sie genau das - kein Aufraeumen, sondern ein Funktionsverlust. tint = sanfte FLAECHE (Statushintergrund), ink = farbige SCHRIFT auf normalem Grund. Die ink-Werte sind Bootstraps *-text-emphasis des dunklen Schemas; ein dunkles Blau wie #1565c0 haette auf #212529 nur 3,0:1. */ --app-tint-red: #3a1f22; --app-tint-amber: #332701; --app-tint-green: #16301f; --app-tint-teal: #123033; --app-tint-blue: #1c2a3f; --app-tint-purple: #292040; --app-ink-red: #ea868f; --app-ink-amber: #ffda6a; --app-ink-green: #75b798; --app-ink-teal: #6edff6; --app-ink-blue: #6ea8fe; --app-ink-purple: #c29ffa; /* --- Cockpit-Stufen ------------------------------------------------------------ */ /* Reihenfolge wie im Hellen: Stufe 1 hebt sich am staerksten von der Grundflaeche ab, Stufe 3 am schwaechsten. Nur die Richtung dreht sich (heller statt dunkler). */ --cockpit-row-1: #343a40; --cockpit-row-2: #2b3035; --cockpit-row-3: #262b30; --cockpit-section: #1e3b38; --cockpit-chosen: #1e3a2a; /* --- Schatten ------------------------------------------------------------------ */ /* Kraeftiger als im Hellen: ein 10-%-Schatten ist auf #212529 schlicht nicht zu sehen. */ --app-shadow-sm: 0 1px 3px rgba(0, 0, 0, 0.4); --app-shadow-md: 0 2px 8px rgba(0, 0, 0, 0.45); --app-shadow-lg: 0 0.5rem 1rem rgba(0, 0, 0, 0.5); } /* ============================================================================ Schriftprofile - 22.08.2026 Die Klasse setzt MainLayout an , passend zu UserSetting.FontProfile. Bewusst NUR --app-font neu belegen: alles andere (Groessen, Abstaende, Farben) bleibt unberuehrt, damit ein Schriftwechsel nichts am Layout verschiebt. Die Ersatzkette hinter der gewaehlten Schrift ist dieselbe wie die Vorgabe. Kommt die Datei nicht an - Netzproblem, alter Browser -, faellt die Anwendung auf die Systemschrift zurueck statt auf irgendeine Standardschrift des Browsers. ============================================================================ */ :root.font-inter { --app-font: 'Inter', system-ui, -apple-system, "Segoe UI", Arial, "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", "Noto Sans CJK SC", sans-serif; } :root.font-source-sans { --app-font: 'Source Sans 3', system-ui, -apple-system, "Segoe UI", Arial, "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", "Noto Sans CJK SC", sans-serif; }