/* ===================================================================== Netsource-Hausfarben für den abgeleiteten Skin "netsource" DIESE DATEI WIRD OHNE ANMELDUNG AUSGELIEFERT. Stylesheets der Anmeldeseite sind öffentlich abrufbar, ihre Kommentare also auch. Deshalb steht hier kein Installationspfad, kein Serverbefund, kein Name und kein Commit. Der Entwurfsbericht, die gemessenen Bestände und die Begründungen liegen im internen Repositorium: docs/roundcube/bauauftrag-bericht-20261018-clemenza.md docs/roundcube/behebung-20261018-clemenza.md (Behebung M4. Die Begründung je Selektor bleibt unten stehen — sie ist der Grund, warum dieser Entwurf prüfbar ist, und sie gibt nichts preis.) WARUM ES DIESE DATEI ÜBERHAUPT GIBT Ein abgeleiteter Skin ohne eigene styles/styles.css hat GAR KEIN Stylesheet: der .min-Rückfall greift beim Laden der Haupt-CSS nicht, und eine styles.min.css dieses Skins existiert nicht. Ergebnis wäre ein Link ins Leere und eine unformatierte Oberfläche. PFADFORM DES @import Gewählt: RELATIV. Eine absolute Form hinge am Montagepunkt des Webmailers im Webserver; die relative Form ist davon unabhängig und löst gegen die URL dieser Datei auf. Zwei Dinge können unabhängig voneinander ausfallen, und sie sehen verschieden aus: (a) Der Import selbst trägt nicht -> die Oberfläche ist vollständig unformatiert (nackter HTML-Fluss). Unübersehbar. (b) Der Import trägt, aber die relativen url()-Verweise INNERHALB der importierten Datei lösen falsch auf -> Layout steht, aber die Symbolschrift fehlt: statt Icons erscheinen leere Kästchen. Prüfschritt nach dem Einspielen ist deshalb NICHT nur "Seite sieht formatiert aus", sondern ausdrücklich: SIND DIE SYMBOLE DA? ===================================================================== */ /* 1. Die vollständige elastic-Fassung zuerst. Ohne diese Zeile ist die Oberfläche unformatiert. Sie MUSS die erste Regel der Datei bleiben: @import ist nur vor allen anderen Regeln gültig. */ @import url("../../elastic/styles/styles.min.css"); /* ===================================================================== H0 — DIE HAUSFARBE, AN GENAU EINER STELLE Umschalten: nur die eine Zeile --netsource-hausfarbe unten ändern. Vorschlag der Markenvorlagen: #F07C00. Bisheriger Wert: #E8811A. Alle Regeln dieser Datei lesen die Farbe über var(); keine Regel nennt sie selbst. (Ausnahme mit Absicht: das Signet images/netsource-signet.svg trägt das Original #F07C00 fest. Es ist ein Markenzeichen, kein Teil des Farbschemas, und folgt dieser Zeile NICHT.) DOKUMENTIERTE AUSNAHME: die helle Fläche #FFF6EC (Ton ca. 32 Grad, Helligkeit ca. 96 %). Sie ist NICHT aus --netsource-hausfarbe abgeleitet und bleibt bei einem Farbwechsel UNVERÄNDERT. Sie steht an zwei Orten: in dieser Datei einmal als Glühen des runden Knopfs (R4) und in meta.json zweimal (theme-color, msapplication-navbutton-color), wo kein var() möglich ist. Wer die Hausfarbe wechselt, prüft diese drei Werte von Hand. Nicht abgeleitet mit Absicht: eine abgeleitete Stufe zöge die Fläche bei einem Wechsel ungeprüft mit (Entscheidung Michael, Nachtrag 17 § 1, A2). DIE ABSTUFUNGEN SIND ABGELEITET, NICHT ZWEITE STELLEN. Überfahren, Klick und Ringe staffelt elastic beim Blau als reine HSL-Helligkeitsstaffelung bei gleichem Ton und gleicher Sättigung (dL = -0,049 / -0,071 / -0,100 / -0,120; behebung-20261018-clemenza.md § 5). Hier entstehen sie durch Mischung mit Schwarz im sRGB-Raum. Für eine Farbe mit HSL-Helligkeit unter 0,5 ist das genau dieselbe Staffelung: Skalieren aller Kanäle hält Ton und Sättigung und skaliert die Helligkeit. #F07C00 hat L = 0,4706, also gilt Anteil = (L + dL) / L: Überfahren Fläche 89,6 % -> #D76F00 (HSL-Rechnung: #D76F00) Überfahren Rahmen 84,9 % -> #CC6900 (#CC6900) Klick Fläche 78,8 % -> #BD6200 (#BD6200) Klick Rahmen 74,5 % -> #B35C00 (#B35C00) Für #E8811A (L = 0,5059) trifft die Mischung die HSL-Werte nur ungefähr: #D07417 statt #D47515, #C56E16 statt #CA6F14, #B76614 statt #BC6813, #AD6013 statt #B36212. Das sind höchstens 6 Stufen je Kanal, dieselbe Richtung, kein anderer Ton. KONTRAST NACH WCAG 2.1, neu gerechnet (relative Leuchtdichte, sRGB): Weiß auf #F07C00 (Knopfschrift) 2,77:1 AA NICHT erfüllt #F07C00 auf #21292c (Dunkelgrund, Text) 5,35:1 AA erfüllt (4,5:1) #F07C00 auf Weiß (Verweise, R1) 2,77:1 AA NICHT erfüllt #F07C00 auf #2c373b (Dunkel-Eingabefeld) 4,42:1 Rahmen, kein Text; für Bedienelemente gilt 3:1 (1.4.11) Weiß auf #D76F00 (Überfahren) 3,41:1 Weiß auf #BD6200 (Klick) 4,28:1 Zum Vergleich der bisherige Wert #E8811A: dieselben gerundeten Zahlen, 2,77:1 und 5,35:1. Der Wechsel ändert an der Lesbarkeit also nichts. Die offene Frage aus dem Grundbau bleibt offen: Weiß auf der Hausfarbe erfüllt AA nicht. Sie gehört nicht in diesen Bau. ÄLTERE BROWSER: color-mix() gibt es seit Chrome 111, Firefox 113 und Safari 16.2. Ein Browser ohne color-mix() würde jede Regel mit einer Abstufung nicht etwa auf eine frühere Angabe zurückfallen lassen, sondern die Eigenschaft ganz verwerfen (ungültig zur Berechnungszeit): der Knopf wäre beim Überfahren durchsichtig. Der @supports-Block unten setzt dort alle Abstufungen auf die Grundfarbe selbst und die Ringe auf die volle Farbe — ohne Staffelung, aber orange und sichtbar. ===================================================================== */ :root { --netsource-hausfarbe: #F07C00; --netsource-hausfarbe-ueber: color-mix(in srgb, var(--netsource-hausfarbe) 89.6%, #000); --netsource-hausfarbe-ueber-rand: color-mix(in srgb, var(--netsource-hausfarbe) 84.9%, #000); --netsource-hausfarbe-klick: color-mix(in srgb, var(--netsource-hausfarbe) 78.8%, #000); --netsource-hausfarbe-klick-rand: color-mix(in srgb, var(--netsource-hausfarbe) 74.5%, #000); --netsource-hausfarbe-ring-knopf: color-mix(in srgb, var(--netsource-hausfarbe) 50%, transparent); --netsource-hausfarbe-ring-klick: color-mix(in srgb, var(--netsource-hausfarbe) 53%, transparent); --netsource-hausfarbe-ring-feld: color-mix(in srgb, var(--netsource-hausfarbe) 25%, transparent); } @supports not (color: color-mix(in srgb, #000 50%, #fff)) { :root { --netsource-hausfarbe-ueber: var(--netsource-hausfarbe); --netsource-hausfarbe-ueber-rand: var(--netsource-hausfarbe); --netsource-hausfarbe-klick: var(--netsource-hausfarbe); --netsource-hausfarbe-klick-rand: var(--netsource-hausfarbe); --netsource-hausfarbe-ring-knopf: var(--netsource-hausfarbe); --netsource-hausfarbe-ring-klick: var(--netsource-hausfarbe); --netsource-hausfarbe-ring-feld: var(--netsource-hausfarbe); } } /* ===================================================================== PRÜFLISTE FÜR SPÄTERE KONTROLLEN — der Ausfall ist stumm Baut elastic in einer künftigen Version Klassennamen um, verschwindet nicht das Branding, sondern nur die Hausfarbe: die Seite sieht einfach wieder aus wie Roundcube, und es fällt niemandem auf. Deshalb sind es wenige, einzeln benannte Selektoren. Ein Prüfschritt sieht sie so nach (im styles-Verzeichnis des Eltern-Skins elastic): grep -o "#37beff" styles.min.css | wc -l # 2026-10-18: 50 grep -o "#00acff" styles.min.css | wc -l # 2026-10-18: 3 BEHEBUNG M6: Hier stand vorher grep -c "#37beff" … # 50. Das ist in der Richtung falsch, die den Prüfschritt unbrauchbar macht: styles.min.css ist minifiziert und enthält NULL Zeilenumbrüche; grep -c zählt Zeilen, nicht Vorkommen, und kann dort nur 0 oder 1 liefern. Gemessen 2026-10-18 an derselben Datei: wc -l < styles.min.css -> 0 grep -c "#37beff" styles.min.css -> 1 (die alte Zahl: 50) grep -o "#37beff" … | wc -l -> 50 grep -c "#00acff" styles.min.css -> 1 grep -o "#00acff" … | wc -l -> 3 Wer den alten Befehl in einem Jahr ausführte, läse 1 statt 50 und stünde vor der Wahl, einen Ausfall zu melden, den es nicht gibt, oder die Abweichung abzutun. Beim zweiten Mal tut er sie ab. und einzeln je Regel unten (jede trägt ihre Nummer): R1 a, .btn-link R2 .btn-primary + Zustände (R2a, Behebung M2) R3 #taskmenu .action-buttons a R4 .floating-action-buttons a.button R5 .folderlist li.mailbox .unreadcount R6 .popupmenu .listing li.selected / .popover .menu li a:hover R7 body (Textfarbe) R2d-R6d dieselben Ziele im DUNKELMODUS (Behebung M1) R2e .btn-primary unter Fokus/Zeiger im Dunkelmodus (Stufe 1b) R8 .form-control:focus, .custom-select:focus (Stufe 1b) R8d dasselbe Eingabefeld im Dunkelmodus (Stufe 1b) H0 die Hausfarbe selbst, eine Zeile (Stufe 1b) Findet eine dieser Grundregeln in einer neuen elastic-Fassung keinen Treffer mehr, ist die zugehörige Hausfarbe ausgefallen. Alle Grundregeln unten sind am 2026-10-18 aus der styles.min.css des Eltern-Skins gemessen (R2e, R8, R8d am 2026-10-20 aus derselben, öffentlich ausgelieferten Datei) und stehen je als Kommentar über der eigenen Regel; die Spezifitätsangaben sind gerechnet, nicht geschätzt (Rechenweg und Prüffälle: behebung-20261018-clemenza.md § 4 und § 5). ===================================================================== */ /* R1 — Links. elastic: a{color:#00acff} .btn-link{color:#00acff} WARUM dieser Selektor und nicht ein allgemeinerer: Die Linkfarbe ist in elastic genau an diesen zwei Stellen als Grundwert gesetzt; alles andere erbt davon. Ein breiterer Griff (etwa über * oder einen Elternknoten) würde auch Flächen treffen, die ihre Farbe bewusst anders setzen. Spezifität: unsere a (0,0,1) / .btn-link (0,1,0) gegen elastics gleiche Selektoren — Gleichstand, unsere steht später, unsere trägt. DUNKELMODUS: Es gibt keine html.dark-mode-Regel, die #00acff als Linkgrundfarbe setzt; diese Regel trägt dort also weiter. Ausnahme, die schon im Hellmodus gilt: html.dark-mode .listing li a{color:#c5d1d3} (0,3,3) schlägt sie INNERHALB von Listen. Das ist elastics Textfarbe für Listeneinträge, keine Linkfarbe, und bleibt bewusst unberührt. */ a, .btn-link { color: var(--netsource-hausfarbe); } /* R2 — Hauptschaltflächen (Anmelden, Senden, Speichern), Grundzustand. elastic: .btn-primary{color:#fff;background:#37beff;border-color:#37beff} WARUM: .btn-primary ist die eine Bootstrap-Klasse, über die elastic ALLE bestätigenden Schaltflächen führt. Spezifität: unsere (0,1,0) gegen elastics (0,1,0) — Gleichstand, unsere steht nach dem @import, unsere trägt. */ .btn-primary, .btn-primary.disabled, .btn-primary:disabled { background: var(--netsource-hausfarbe); border-color: var(--netsource-hausfarbe); } /* R2a — BEHEBUNG M2: die Zustände derselben Schaltfläche. Hier stand vorher nur R2 mit dem Kommentar "Die drei Zustände stehen in elastic in getrennten Regeln; der disabled-Zustand wird hier mitgenommen". Gemessen führt elastic .btn-primary in SECHS Regeln, und mitgenommen war der eine Zustand, der sich im Betrieb am seltensten zeigt. Die Folge war sichtbar, und zwar auf der Anmeldeseite — der einzigen Seite, die auch Nichtkunden sehen: Der Knopf "Anmelden" war orange, wurde BLAU, sobald der Mauszeiger darüberstand, war blau im Augenblick des Klicks und trug danach einen blauen Fokusring. Gemessene elastic-Regeln und die gerechnete Spezifität: .btn-primary (0,1,0) .btn-primary.disabled, .btn-primary:disabled (0,2,0) .btn-primary:hover{background:#1eb6ff;border-color:#13b2ff} (0,2,0) .btn-primary:focus{…;box-shadow:0 0 0 .2rem rgba(55,190,255,.5)} (0,2,0) .btn-primary:not(:disabled):not(.disabled).active, .btn-primary:not(:disabled):not(.disabled):active{background:#04adff; border-color:#00a8f9} (0,4,0) .btn-primary:not(:disabled):not(.disabled).active:focus, …:active:focus{box-shadow:…rgba(55,190,255,.53)} (0,5,0) Bei :hover und :focus war die Spezifität unserer Grundregel (0,1,0) NIEDRIGER — die Regel stand dort also gar nicht im Wettbewerb, weil sie den Zustand nicht benennt. Die Regeln unten benennen ihn und treffen die Spezifität der elastic-Regel auf die Stelle genau; bei Gleichstand entscheidet die Reihenfolge, und sie stehen nach dem @import. WARUM genau diese vier und nicht ein Sammelselektor: Jede der vier deckt eine elastic-Regel ab, die einen eigenen Farbwert führt. Ein gemeinsamer Selektor mit nur einem Wert würde die Abstufung einziehen, die elastic zwischen Überfahren und Klick macht — der Knopf gäbe beim Drücken keine Rückmeldung mehr. DIE FARBABSTUFUNGEN SIND ABGELEITET, NICHT GEWÄHLT: elastic staffelt #37beff -> #1eb6ff (hover) -> #04adff (active) und die Rahmen #13b2ff / #00a8f9. Das ist in HSL eine reine Helligkeitsstaffelung bei gleichem Ton und gleicher Sättigung (dL = -0,049 / -0,071 / -0,100 / -0,120). Dieselben vier Deltas, auf die Hausfarbe angewandt, ergeben die Werte unten. Rechenweg: behebung-20261018-clemenza.md § 5. Seit Stufe 1b stehen die Werte nicht mehr fest hier, sondern werden in H0 aus der einen Hausfarbe abgeleitet. ERKENNUNGSMERKMAL, woran man das Greifen sieht: Auf der abgemeldeten Anmeldeseite den Mauszeiger über "Anmelden" halten — der Knopf muss orange bleiben und eine Spur dunkler werden, nicht blau. Nach dem Klick darf der Fokusring nicht blau sein. */ .btn-primary:hover { background: var(--netsource-hausfarbe-ueber); border-color: var(--netsource-hausfarbe-ueber-rand); } .btn-primary:focus { background: var(--netsource-hausfarbe-ueber); border-color: var(--netsource-hausfarbe-ueber-rand); box-shadow: 0 0 0 .2rem var(--netsource-hausfarbe-ring-knopf); } .btn-primary:not(:disabled):not(.disabled).active, .btn-primary:not(:disabled):not(.disabled):active { background: var(--netsource-hausfarbe-klick); border-color: var(--netsource-hausfarbe-klick-rand); } .btn-primary:not(:disabled):not(.disabled).active:focus, .btn-primary:not(:disabled):not(.disabled):active:focus { box-shadow: 0 0 0 .2rem var(--netsource-hausfarbe-ring-klick); } /* R3 — Hauptnavigation links (Mail, Kontakte, Einstellungen). elastic: #taskmenu .action-buttons a{color:#37beff;background:0 0} #taskmenu .action-buttons a:hover{color:#37beff;background:#45555c} WARUM: Das Taskmenü ist dauerhaft sichtbar und damit die Stelle, an der die Hausfarbe den Gesamteindruck trägt. Der Griff geht ausdrücklich auf #taskmenu .action-buttons a und nicht auf #taskmenu insgesamt — dessen Grundregel (#taskmenu{z-index:30001;overflow-x:hidden}) führt keine Farbe, eine Farbe dort zu setzen würde also eine fremde Schicht einführen. Spezifität: unsere (1,1,1) gegen elastics (1,1,1) — Gleichstand, unsere trägt. */ #taskmenu .action-buttons a, #taskmenu .action-buttons a:hover { color: var(--netsource-hausfarbe); } /* R4 — runder Knopf "Neue Nachricht" (floating action button). elastic: .floating-action-buttons a.button{...background:#37beff;color:#fff; box-shadow:0 0 5px 5px #eaf8ff;...} WARUM: eigener Selektor statt .btn-primary, weil elastic diesen Knopf NICHT über .btn-primary führt — ohne eigene Regel bliebe er blau. Hier steht zugleich die einzige Stelle, an der die helle Hausfarbe #FFF6EC in dieser Datei vorkommt: sie ersetzt das hellblaue Glühen #eaf8ff. #FFF6EC ist ansonsten die Hintergrundfarbe der dunklen Logovariante, keine Flächenfarbe der Oberfläche — ein großflächiger Einsatz hätte einen Selektor gebraucht, den ich nicht gemessen habe, und ein geratener Selektor ist genau der stumme Ausfall, gegen den diese Datei geschrieben ist. Spezifität: unsere (0,2,1) gegen elastics (0,2,1) — Gleichstand. */ .floating-action-buttons a.button { background: var(--netsource-hausfarbe); box-shadow: 0 0 5px 5px #FFF6EC; } /* R5 — Zähler ungelesener Nachrichten an den Ordnern. elastic: .folderlist li.mailbox .unreadcount{...background:#37beff;color:#fff;...} .folderlist li.mailbox.recent>a>.unreadcount{background:#37beff;color:#fff} WARUM: kleine Fläche, aber die am häufigsten angesehene der ganzen Oberfläche. Beide elastic-Regeln werden getroffen, weil die zweite die erste bei neuer Post überschreibt — nur eine zu setzen hieße, dass die Farbe beim Eintreffen von Post zurückspringt. Spezifität: unsere (0,3,1) bzw. (0,4,3) gegen elastics gleiche Selektoren — Gleichstand. */ .folderlist li.mailbox .unreadcount, .folderlist li.mailbox.recent > a > .unreadcount { background: var(--netsource-hausfarbe); } /* R6 — Auswahl und Überfahren in Menüs. elastic: .popupmenu .listing li.selected{color:#fff;background-color:#37beff} .popupmenu .listing li>a:not(.disabled):hover{color:#fff;background-color:#37beff} .popover .menu li a:not(.disabled):hover{color:#fff;background-color:#37beff} WARUM: die drei Selektoren sind in elastic getrennt, meinen aber dieselbe Geste (ausgewählter bzw. überfahrener Menüeintrag). Sie zusammenzufassen ist die kleinste Fassung, die die Geste vollständig abdeckt; einzelne davon wegzulassen hieße, dass dieselbe Liste je nach Zustand zwei Farben zeigt. Spezifität: unsere (0,3,2) / (0,4,2) / (0,4,2) gegen elastics gleiche Selektoren — Gleichstand. */ .popupmenu .listing li.selected, .popupmenu .listing li > a:not(.disabled):hover, .popover .menu li a:not(.disabled):hover { background-color: var(--netsource-hausfarbe); } /* R7 — Grundtextfarbe. elastic: body{min-width:240px;height:100%;color:#2c363a;overflow:hidden} WARUM body und nicht html oder ein Sammelselektor: #2c363a ist in elastic genau hier als Grundwert gesetzt, alles Weitere erbt. Der Dunkelmodus bleibt bewusst unberührt — er setzt html.dark-mode body{color:#c5d1d3} mit der Spezifität (0,1,2) gegen unsere (0,0,1), also höher. Das ist beabsichtigt: #222222 auf dunklem Grund wäre unlesbar. Dies ist die EINE Regel, bei der elastics Dunkelfassung gewinnen SOLL. */ body { color: #222222; } /* ===================================================================== DUNKELMODUS — BEHEBUNG M1 DER MANGEL: Von den sieben Regeln darüber wirkte im Dunkelmodus genau EINE (R1, die Linkfarbe). Die Datei behandelte den Dunkelmodus an genau einer Stelle — bei R7 — und sagte dort richtig, er bleibe bewusst unberührt. Diese eine korrekte Betrachtung erzeugte den Eindruck, die Frage sei für die ganze Datei geprüft. Sie war es nicht. Zugleich erklärt meta.json den Dunkelmodus mit "dark_mode_support": true ausdrücklich für unterstützt, und die Prüfliste des Einspielskripts fragte dort nur nach "lesbarer Text" — also nach LESBARKEIT, nicht nach der Hausfarbe. Ein Prüfer, der der Liste folgte, hakte den Punkt ab, ohne ihn geprüft zu haben. Beides ist mitbehoben (Skript Schritt 6 Nr. 5). WARUM das nicht auffällt: Es bricht nichts. Die Oberfläche ist im Dunkelmodus einfach wieder blau — Hauptschaltflächen, Hauptnavigation, der runde Knopf, die Menüauswahl, der Ungelesen-Zähler. Sie sieht aus wie Roundcube, und das sieht nach Absicht aus. DAS MITTEL: elastics Dunkelregeln tragen das Präfix html.dark-mode und schlagen unsere präfixlosen Regeln nach Spezifität. Je betroffener Regel steht unten eine zweite mit DEMSELBEN Präfix — damit ist die Spezifität gleich und die Reihenfolge entscheidet; unsere steht nach dem @import. Gerechnet, nicht geschätzt (Rechenweg: Behebungsbericht § 4): Ziel unsere Hellregel elastics Dunkelregel unsere Dunkelregel R2 0,1,0 verliert 0,2,1 0,2,1 Gleichstand R3 1,1,1 verliert 1,2,2 1,2,2 Gleichstand R4 0,2,1 verliert 0,3,2 0,3,2 Gleichstand R5 0,3,1 verliert 0,4,2 0,4,2 Gleichstand R6 0,4,2 verliert 0,5,3 0,5,3 Gleichstand R7 0,0,1 verliert 0,1,2 — so gewollt DIE FARBWAHL IST GEMESSEN, NICHT GERATEN. Kontrast nach WCAG 2.1 gegen elastics Dunkelgrund #21292c: Hausfarbe als TEXTFARBE auf #21292c 5,35:1 erfüllt AA (4,5:1) (gilt für #E8811A und #F07C00 gleich, siehe H0) elastics #37beff als Vergleich 7,03:1 elastics Dunkeltext #c5d1d3 9,47:1 Als Textfarbe (R3d) trägt die Hausfarbe damit. Als FLÄCHE wird sie unverändert übernommen, damit der Knopf in beiden Betriebsarten dieselbe Farbe hat; dort setzen die Regeln ausdrücklich color:#fff, weil elastic im Dunkelmodus color:#e2e8e9 setzt und dieser Ton auf Orange den schlechteren Kontrast gibt (2,23:1 gegen 2,77:1). OFFEN UND NICHT VON MIR ENTSCHIEDEN: Weiße Schrift auf der Hausfarbe ergibt 2,77:1 und erfüllt WCAG AA damit NICHT. Das gilt schon im Hellmodus und schon im Grundbau — es ist kein Mangel dieser Behebung, sondern einer, den sie sichtbar macht. Eine andere Schriftfarbe auf den Hauptschaltflächen ist eine Gestaltungsentscheidung mit Außenwirkung (Anmeldeseite) und gehört nicht in eine Mängelbehebung. Vorgelegt mit Zahlen im Behebungsbericht § 8. ERKENNUNGSMERKMAL, woran man das Greifen sieht: Dunkelmodus einschalten und EINZELN nachsehen — Hauptschaltfläche (auch beim Überfahren), Hauptnavigation, runder Knopf, Ungelesen-Zähler. Alle vier müssen orange sein. Ist eines blau, wirkt die zugehörige Regel nicht. Die Prüfliste des Einspielskripts fragt das jetzt so ab. ===================================================================== */ /* R2d — Hauptschaltflächen im Dunkelmodus. elastic: html.dark-mode .btn-primary{background-color:#006a9d;color:#e2e8e9} html.dark-mode .btn-primary:hover:not(:disabled){background-color:#007bb7} WARUM background-color und nicht background: elastic setzt im Dunkelmodus die Langform; eine Kurzform background würde zusätzlich Bildebene und Position zurücksetzen, die hier nichts zu suchen haben. Der Rahmen braucht keine Dunkelregel — elastic setzt dort keine, also trägt R2 aus dem Hellteil weiter. */ html.dark-mode .btn-primary { background-color: var(--netsource-hausfarbe); color: #fff; } html.dark-mode .btn-primary:hover:not(:disabled) { background-color: var(--netsource-hausfarbe-ueber); } /* R2e — Stufe 1b: DIALOGKNÖPFE IM DUNKELMODUS, und mit ihnen jede Hauptschaltfläche unter Fokus oder Mauszeiger. DER AUFTRAG nahm an, in Dialogfenstern erscheine im Dunkelmodus elastic-Blau, weil elastics Regel html.dark-mode .ui-dialog .ui-dialog-buttonpane .ui-dialog-buttonset button.btn-primary:not(.btn-danger){color:#c5d1d3} (0,6,2) nicht überschrieben ist. Gemessen trifft das nicht zu: (a) Diese Regel steht in elastic NUR in @media screen and (max-width:480px), also nur in der Telefon- ansicht (Quelltext 1.6.19: skins/elastic/styles/dark.less, Z. 913-918). Dort und nur dort macht elastic die Dialogknöpfe zu flachen Symbolknöpfen ohne Fläche — hell #2c363a, dunkel #c5d1d3 (widgets/jqueryui.less Z. 235-239, im @media-Block ab Z. 170). Das ist Grau, kein Blau, und in beiden Betriebsarten gleich. Es bleibt bewusst unberührt: eine orange Fläche nur im Dunkelmodus der Telefonansicht wiche vom Hellmodus derselben Ansicht ab. (b) Auf dem Schreibtisch trägt ein Dialogknopf die Klassen ui-button … btn btn-primary (jQuery UI plus elastic ui.js Z. 844-845). Im Dunkelmodus greift dort R2d (0,2,1) und schlägt jquery-ui.min.css .ui-button{background:#f6f6f6} (0,1,0): Die Fläche ist schon orange. Gemessen an einer Nachbildung mit den ausgelieferten Stylesheets, Fokus weggenommen: Fläche #F07C00, Schrift #fff. DIE TATSÄCHLICHE LÜCKE liegt eine Regel daneben: html.dark-mode .btn:focus,html.dark-mode .btn:hover{color:#e2e8e9} (0,3,1) schlägt R2d (0,2,1) bei der Schriftfarbe. Ein Dialogknopf öffnet MIT Fokus (jQuery UI setzt ihn auf den ersten Knopf), und der Knopf "Anmelden" bekommt ihn beim Überfahren und nach dem Klick. Gemessen unter Fokus: Fläche #F07C00, Schrift #e2e8e9 — 2,23:1 statt 2,77:1, genau der Ton, den R2d aus diesem Grund ausdrücklich vermeidet. Spezifität: unsere (0,3,1) gegen elastics (0,3,1) — Gleichstand, unsere steht später. Gegen die Telefonregel oben (0,6,2) verliert sie, und das ist so gewollt (a). NICHT BEHOBEN, weil nicht beauftragt und kein Dunkelmodus: Im HELLMODUS ist ein Dialogknopf OHNE Fokus grau (#f6f6f6, Schrift #454545), weil jquery-ui.min.css nach diesem Stylesheet geladen wird und .ui-button dieselbe Spezifität wie .btn-primary hat. Das gilt für elastic im Werkszustand genauso (Blau statt Orange nur unter Fokus). Vorgelegt im Bericht der Stufe 1b. */ html.dark-mode .btn-primary:focus, html.dark-mode .btn-primary:hover { color: #fff; } /* R3d — Hauptnavigation im Dunkelmodus. elastic: html.dark-mode #taskmenu .action-buttons a{color:#37beff} Dies ist die einzige der fünf Dunkelregeln, die eine TEXTFARBE setzt; deshalb ist hier der Kontrast maßgeblich: Hausfarbe auf #21292c = 5,35:1 (H0). */ html.dark-mode #taskmenu .action-buttons a { color: var(--netsource-hausfarbe); } /* R4d — runder Knopf "Neue Nachricht" im Dunkelmodus. elastic: html.dark-mode .floating-action-buttons a.button{box-shadow:none; background:#006a9d} elastic nimmt im Dunkelmodus das Glühen ausdrücklich WEG (box-shadow: none). Das bleibt so — ein helles Glühen um einen Knopf auf dunklem Grund wäre ein Fremdkörper. Übernommen wird nur die Fläche. */ html.dark-mode .floating-action-buttons a.button { background: var(--netsource-hausfarbe); } /* R5d — Ungelesen-Zähler im Dunkelmodus. elastic: html.dark-mode .folderlist li.mailbox .unreadcount{ background-color:#4d6066;color:#e2e8e9;font-weight:400} Beachten: elastic führt im Dunkelmodus KEINE Regel für den .recent-Zustand. Dort trägt also R5 aus dem Hellteil weiter, und die Farbe springt beim Eintreffen von Post nicht um. Die zweite Zeile unten ist dennoch gesetzt, damit das auch dann gilt, wenn elastic eine solche Dunkelregel nachträglich einführt — sonst wäre genau das wieder ein stummer Ausfall. */ html.dark-mode .folderlist li.mailbox .unreadcount, html.dark-mode .folderlist li.mailbox.recent > a > .unreadcount { background-color: var(--netsource-hausfarbe); color: #fff; } /* R6d — Auswahl und Überfahren in Menüs im Dunkelmodus. elastic: html.dark-mode .popupmenu .listing li>a:not(.disabled):hover — Teil einer Sammelregel mit {background-color:#374549} Beachten: elastic führt im Dunkelmodus KEINE eigene Regel für .popupmenu .listing li.selected und keine für .popover .menu li a:hover mit dieser Grundfarbe. Für den ersten Fall trägt R6 aus dem Hellteil. Für den zweiten gibt es eine Sammelregel html.dark-mode .menu a:not(.disabled):hover (0,4,2), die unserer .popover-Regel (0,4,2) gleichkommt — Gleichstand, unsere steht später. Alle drei stehen unten dennoch mit Präfix, aus demselben Grund wie bei R5d: damit eine künftige elastic-Dunkelregel sie nicht stumm aushebelt. */ html.dark-mode .popupmenu .listing li.selected, html.dark-mode .popupmenu .listing li > a:not(.disabled):hover, html.dark-mode .popover .menu li a:not(.disabled):hover { background-color: var(--netsource-hausfarbe); color: #fff; } /* ===================================================================== FOKUSRAHMEN DER EINGABEFELDER — Stufe 1b DER BEFUND (Nachweis "vorher" an der Anmeldeseite): Der Rahmen um das Feld, in dem der Cursor steht, war in beiden Betriebsarten elastic-Blau. Das ist die erste Stelle, an der ein Besucher der Anmeldeseite etwas tut, und sie war die einzige blaue. ERKENNUNGSMERKMAL: Auf der Anmeldeseite ins Benutzerfeld klicken — Rahmen und Schein orange, hell wie dunkel. Ist eines blau, wirkt die zugehörige Regel nicht. BEWUSST NICHT ERFASST (alle hinter der Anmeldung, nicht gesehen, und jeweils mit eigenem Selektor in elastic): .input-group-text input:focus (mit !important), .input-group a:focus, .custom-file-input:focus, .custom-switch, .recipient-input.focus, .multi-input .content.focused, CodeMirror und der Editor TinyMCE (div.tox). Sie bleiben blau, bis jemand sie am laufenden Webmail gesehen hat. ===================================================================== */ /* R8 — Fokusrahmen, Hellmodus (und Grundlage für den Dunkelmodus). elastic: .form-control:focus{color:#2c363a;border-color:#37beff; box-shadow:0 0 0 .2rem rgba(55,190,255,.25)} (0,2,0) bootstrap: .custom-select:focus{border-color:#80bdff;outline:0; box-shadow:0 0 0 .2rem rgba(0,123,255,.25)} (0,2,0) (elastic überschreibt das Auswahlfeld nicht; es bliebe Bootstrap-Blau, auch in den Einstellungen) Spezifität: unsere (0,2,0) gegen beide (0,2,0) — Gleichstand, unsere steht nach dem @import und nach bootstrap.min.css (die Seite lädt sie vorher). Die Schriftfarbe von elastic bleibt unberührt. UNBERÜHRT UND SO GEWOLLT: .form-control.is-invalid:focus (0,3,0) bleibt rot — ein fehlerhaftes Feld soll rot bleiben, auch mit Fokus. Im Dunkelmodus gibt es für box-shadow keine elastic-Regel; der Schein dieser Regel trägt dort also weiter. */ .form-control:focus, .custom-select:focus { border-color: var(--netsource-hausfarbe); box-shadow: 0 0 0 .2rem var(--netsource-hausfarbe-ring-feld); } /* R8d — Fokusrahmen im Dunkelmodus. elastic: html.dark-mode .custom-file-label:focus:not(.is-invalid), html.dark-mode .form-control:focus:not(.is-invalid){ color:#e2e7e9!important;border-color:#37beff} (0,4,1) Übernommen wird nur der zweite Selektor (das Eingabefeld) und nur die Rahmenfarbe; die Schriftfarbe mit !important bleibt elastics. Spezifität: unsere (0,4,1) gegen elastics (0,4,1) — Gleichstand, unsere steht später. Kontrast des Rahmens gegen den dunklen Feldgrund #2c373b: 4,42:1 (H0), über den 3:1, die WCAG 1.4.11 für Bedienelemente verlangt. */ html.dark-mode .form-control:focus:not(.is-invalid) { border-color: var(--netsource-hausfarbe); }