/-Fläche nutzt, die nicht über --background-color läuft. Attributselektor auf autocomplete/type deckt die Login-Formularfelder ab, unabhängig von Klassennamen. */ body { background-color: var(--prowerb-bg); } input[type="email"], input[type="password"], input[type="text"][name*="login" i], input[autocomplete="username"], input[autocomplete="current-password"], input[autocomplete="new-password"] { font-family: var(--prowerb-font-body); color: var(--prowerb-ink); } /* ============================================================================ * 5) AKZENT- & BUTTON-FARBEN — Ebene A: verifizierte Theme-Tokens * ============================================================================ * DocSpace berechnet Akzentfarben aus vier Basis-Variablen, die React PER * INLINE-STYLE auf :root UND setzt (components/theme-provider, * docspace-ui-kit-react) — deshalb zwingend !important, sonst verliert * jede externe Stylesheet-Regel gegen den Inline-Style: * --color-scheme-main-accent Akzentfarbe (Links, aktive Icons, Ränder) * --color-scheme-text-accent Textfarbe für akzentuierten Text * --color-scheme-main-buttons Hintergrund primärer Buttons * --color-scheme-text-buttons Textfarbe auf primären Buttons * Daraus leitet DocSpace intern (theme.scss) --accent-main, --accent-text, * --accent-button, --accent-button-text ab — die wir zusätzlich direkt * überschreiben, für den Fall, dass die Inline-Properties (z. B. weil kein * Custom-Color-Theme aktiv ist) gar nicht erst gesetzt werden und DocSpace * sonst auf seinen Standard-Blauton zurückfiele. * * WICHTIG — Rot ist Signal, nicht Fläche: Diese Variablen steuern laut * DocSpace-Quellcode ausschließlich Buttons, Links, Fokus-/Aktiv-Zustände * und kleinteilige UI-Elemente (Filter-Tags, Floating-Button, Avatar-Hover- * Overlay) — NICHT großflächige Hintergründe. Es wird hier bewusst KEINE * Regel ergänzt, die --prowerb-red als --background-color o. Ä. einsetzt. */ :root, body { --color-scheme-main-accent: var(--prowerb-red) !important; --color-scheme-text-accent: var(--prowerb-red) !important; --color-scheme-main-buttons: var(--prowerb-red) !important; --color-scheme-text-buttons: var(--prowerb-white) !important; --accent-main: var(--prowerb-red) !important; --accent-text: var(--prowerb-red) !important; --accent-button: var(--prowerb-red) !important; --accent-button-text: var(--prowerb-white) !important; --link-color: var(--prowerb-red) !important; --button-color-base: var(--prowerb-ink) !important; --button-color-base-hover: var(--prowerb-ink) !important; --button-color-base-active: var(--prowerb-ink) !important; --button-background-base: var(--prowerb-white) !important; --button-background-base-hover: var(--prowerb-bg) !important; --input-border-focus: var(--prowerb-red) !important; } /* Ebene B: generische Buttons/Links/ARIA-Rollen als zweite Verteidigungs- * linie, falls einzelne Komponenten Farben fest verdrahtet statt über * var(--accent-*) zu lesen. Bewusst NICHT als background auf großflächige * Container (div, section, main) angewendet — nur auf tatsächlich * interaktive/kleinteilige Elemente, damit Rot Signal bleibt. * * Hinweis Kontrast: weißer Text auf --prowerb-red erreicht 4,40:1 (siehe * Abschnitt 2) — ausreichend für Buttons mit Montserrat SemiBold/Bold ab * 14px, wie sie DocSpace für Button-Beschriftungen durchgehend verwendet. * Bei zusätzlichen, sehr kleinen (<14px) roten Flächen mit weißem Text * diesen Kontrast erneut prüfen. */ button[type="submit"], button[class*="primary" i], [role="button"][class*="primary" i], a[class*="button" i][class*="primary" i] { background-color: var(--prowerb-red); color: var(--prowerb-white); border-color: var(--prowerb-red); font-family: var(--prowerb-font-body); font-weight: 600; } button[type="submit"]:hover, button[class*="primary" i]:hover, [role="button"][class*="primary" i]:hover { background-color: var(--prowerb-red-hover); border-color: var(--prowerb-red-hover); } button[type="submit"]:active, button[class*="primary" i]:active, [role="button"][class*="primary" i]:active { background-color: var(--prowerb-red-active); border-color: var(--prowerb-red-active); } /* ============================================================================ * 6) LOGOS — Ebene A: verifizierte IDs/Klassennamen aus dem DocSpace-Quellcode * ============================================================================ * Diese Selektoren sind KEIN Rätselraten, sondern 1:1 aus dem Quellcode * übernommen (Stand 2026-08-11, @docspace/shared 3.7.1 / master): * - Login-Seite (packages/login/src/components/Logo/index.tsx): * * * Beide Bilder werden IMMER beide gerendert; welches sichtbar ist, * steuert DocSpace selbst über Theme-CSS. Wir tauschen bei BEIDEN das * Bild aus (per nginx-Interception auf /logo.ashx, siehe * nginx/conf.d/prowerb-branding.conf) und sichern hier zusätzlich per * CSS die Zielgröße ab, damit unser Logo (Seitenverhältnis ≈5,5:1, * branding/assets/README.md) nicht in DocSpace' eigenes 810×92-Slot- * Seitenverhältnis (≈8,8:1) gezwungen wird. * - Kopfzeile, eingeloggt (packages/client/.../NavMenu/sub-components/ * header.js): * - Eingeklapptes Menü (docspace-ui-kit-react, components/article/ * sub-components/Header.tsx): bzw. * */ #logo-image-light, #logo-image-dark, .logo-wrapper { height: 44px; width: auto; max-width: min(386px, 60vw); object-fit: contain; } .header-logo-icon, .logo-icon_svg, .burger-logo { height: 32px; width: auto; max-width: 100%; object-fit: contain; } /* Mobile: DocSpace verwendet für die Login-Seite selbst 24px Logo-Höhe auf kleinen Screens (siehe Logo/index.tsx: logoHeight = isMobile ? 24 : 44). Wir übernehmen dieselbe Schwelle, damit unser Logo im selben Rhythmus skaliert. 24px entspricht exakt der in der Markenvorgabe genannten Mindestgröße — kleiner wird bewusst nicht skaliert. */ @media (max-width: 600px) { #logo-image-light, #logo-image-dark, .logo-wrapper { height: 24px; max-width: min(211px, 70vw); } .header-logo-icon, .logo-icon_svg, .burger-logo { height: 24px; } } /* ============================================================================ * 7) LINKS — Kontrast-Mitigation (siehe Berechnung in Abschnitt 2) * ============================================================================ * PROWERB-Rot als Textfarbe liegt bei 4,07–4,40:1 auf hellem Grund — unter * der 4,5:1-Schwelle für normalen Fließtext, aber über 3:1 für UI- * Komponenten/große Schrift. WCAG SC 1.4.1 verlangt zusätzlich, Links nicht * NUR über Farbe zu kennzeichnen — deshalb hier durchgehend Unterstrich * statt reiner Farbmarkierung. Für generischen -Fließtext (potenziell * <14px) zusätzlich als Sicherheitsnetz keine reine Rot-auf-Hell-Fläche * ohne Unterstreichung. */ a { color: var(--prowerb-red); text-decoration: underline; text-decoration-thickness: 1px; text-underline-offset: 2px; font-family: var(--prowerb-font-body); } a:hover { color: var(--prowerb-red-hover); } a:active { color: var(--prowerb-red-active); } /* Navigationslinks/Menüpunkte, die DocSpace typischerweise ohne Unterstreichung als eigenständige UI-Elemente stylt (nav, [role="menuitem"], [role="tab"]) - hier zählt der 3:1-UI-Komponenten-Massstab, Unterstrich wäre optisch falsch. Bewusst getrennt von normalem Fliesstext-Link oben. */ nav a, [role="menuitem"], [role="tab"], [role="navigation"] a { text-decoration: none; } nav a[aria-current], [role="tab"][aria-selected="true"], [aria-current="page"] { color: var(--prowerb-red); font-weight: 600; } /* ============================================================================ * 8) FOKUSZUSTÄNDE — Barrierefreiheit, Ebene B (generisch, elementtypbasiert) * ============================================================================ * :focus-visible statt :focus, damit der Ring nur bei Tastaturnavigation * erscheint (kein Ring nach Maus-Klick) — Standardverhalten moderner * Browser und barrierefreiheitsfreundlich. 2px Kontur in PROWERB-Rot auf * praktisch jedem Hintergrund dieser Datei (Weiß/Hintergrund/Ink) erfüllt * den 3:1-Massstab für Non-Text-Contrast (WCAG 2.1 SC 1.4.11): Rot auf Ink * 3,73:1, Rot auf Weiß/Hintergrund 4,07–4,40:1 (siehe Abschnitt 2). */ a:focus-visible, button:focus-visible, input:focus-visible, textarea:focus-visible, select:focus-visible, [role="button"]:focus-visible, [tabindex]:focus-visible { outline: var(--prowerb-focus-ring-width) solid var(--prowerb-red); outline-offset: 2px; } /* ============================================================================ * 9) RESPONSIVE / MOBILGERÄTE — allgemeine Absicherung * ============================================================================ * Keine der obigen Regeln verwendet feste Pixelbreiten für Container- * Elemente (nur Logo-Höhen, s. Abschnitt 6, mit max-width in vw/min() * kombiniert). Diese Zeilen fangen zusätzlich lange, unbrechbare Inhalte * (z. B. E-Mail-Adressen in Login-Feldern) auf schmalen Viewports ab. */ * { box-sizing: border-box; } body, input, textarea { max-width: 100vw; overflow-wrap: break-word; } /* ============================================================================ * 10) DUNKLES THEME — Kontrast-Gegenprobe * ============================================================================ * DocSpace unterscheidet Light/Dark über body.light / body.dark bzw. * html[data-theme="light|dark"] (theme-provider/index.tsx). Alle Farb- * Overrides oben sind Theme-unabhängig auf :root/body gesetzt und gelten * daher in BEIDEN Modi identisch. Das ist beabsichtigt: PROWERB-Rot auf * PROWERB-Ink (dunkles Theme, Buttons/Akzente) liegt bei 3,73:1 (Abschnitt * 2) — ausreichend für Buttons/Fokusringe, nicht für Fließtext. Für * Fließtext im dunklen Theme bleibt --text-color bewusst NICHT auf Rot * gesetzt (nur --prowerb-white via DocSpace' eigenem --text-color: white * im .dark-Scope, den wir hier nicht anfassen). */ /* =========================================================================== NACHTRAEGLICHE KORREKTUREN Empirisch an der laufenden Instanz gemessen (DocSpace 3.7.2.1), nicht geraten. Stehen bewusst am Dateiende, damit sie in der Kaskade gewinnen. =========================================================================== */ /* 1) Logo auf Login- und Wizard-Seite ------------------------------------- Gemessen: .logo-wrapper ist 21,9 x 44 px bei object-fit: contain. DocSpace bemisst diesen Slot fuer ein kompaktes, nahezu quadratisches Zeichen. Das PROWERB-Logo ist horizontal (800 x 146, Verhaeltnis rund 5,5:1) und schrumpft darin auf etwa 22 x 4 px -- praktisch unsichtbar und deutlich unter der Mindestgroesse von 24 px aus den Markenregeln. Die Klasse .logo-wrapper traegt keinen Build-Hash und ist damit updatestabil. Zweite Ursache, empirisch gefunden: Die gelieferten SVG trugen nur ein viewBox, aber keine width/height am Wurzelelement. Der Browser vergibt dann eine Ersatz-Eigengroesse (hier 300 x 55) und object-fit skaliert die Zeichnung nicht auf die Box hoch -- das Logo blieb ein Splitter in einer korrekt bemessenen Box. Die Assets tragen die Masse jetzt explizit; an der Zeichnung selbst wurde nichts geaendert. */ .logo-wrapper { width: 240px !important; max-width: 100% !important; height: 44px !important; object-fit: contain !important; object-position: center !important; } /* 2) Ueberschriften in Krona One ------------------------------------------ Gemessen: DocSpace rendert Ueberschriften als

mit CSS-Modules-Klassen, nicht als h1/h2. Elementselektoren allein greifen deshalb nie -- vor dieser Korrektur war Krona One auf der gesamten Seite an null Stellen aktiv. Der Hash am Ende der Klassennamen aendert sich bei jedem DocSpace-Build, der Praefix davor nicht. Darum Teilstring-Selektoren statt exakter Klassen. Krona One gibt es nur in Schnitt 400; ohne die Gewichtsangabe wuerde der Browser einen unsauberen Fettschnitt simulieren. Bewusst NUR auf echte Headlines. Krona One baut deutlich breiter als Montserrat: auf der Formular-Zwischenueberschrift lief der Text dadurch auf drei Zeilen und drueckte das Layout auseinander. Zwischenueberschriften und Labels bleiben deshalb in Montserrat. Die Marke sieht Krona One fuer Headlines vor, nicht fuer Beschriftungen. */ h1, h2, .greeting-title, [class*="greeting-title"] { font-family: "Krona One", "Montserrat", "Segoe UI", Arial, sans-serif !important; font-weight: 400 !important; letter-spacing: 0; } /* 3) Umbrechende Beschriftungen ------------------------------------------- Gemessen: Montserrat baut breiter als die Originalschrift. DocSpace vergibt der Beschriftungsspalte eine feste Breite von 59 px; darin brechen "Language" und "Timezone" auf zwei Zeilen um, "Domain" nicht. Das war eine Regression durch den Schriftwechsel, kein Fehler von DocSpace. Loesung: Spalte an den Inhalt anpassen statt Schrift zu verkleinern. */ [class*="infoWrapper"] { grid-template-columns: auto minmax(0, 1fr) !important; column-gap: 16px; align-items: center; }