/* Farb-/Form-Theme des Shops - EINZIGE Stelle, an der Marken-Farbwerte stehen. Ein Shop-Betreiber tauscht sein Branding aus, indem er nur diese Datei ersetzt (oder einzelne Werte über CustomizingAssets.ZusaetzlicheStylesheets überschreibt, siehe App.razor) - niemals durch Änderungen an webshop.css, wo ausschließlich mit diesen Tokens gearbeitet wird. Ladereihenfolge (App.razor): blazorblueprint.css -> themes.css -> DIESE DATEI -> webshop.css. Muss NACH themes.css kommen: BlazorBlueprint definiert seine OKLCH-Tokens dort unter Attribut-Selektoren ([data-base-color="zinc"] usw.), die per JS erst nach der Hydration auf gesetzt werden. Dieser ungescopte :root-Block hat dieselbe Spezifität, gewinnt über die spätere Position - und greift zusätzlich schon beim allerersten Paint, bevor ThemeService.InitializeAsync() gelaufen ist. Farbwerte stammen aus dem "sales"-Theme der DeDeNet-Website. Bewusst NUR die Markenfarben - die neutralen Grautöne (--background/--foreground/--card/--border/--muted) bleiben unverändert bei BlazorBlueprints Zinc-Basis. Bewusst NICHT gesetzt bleibt die font-family (der Shop behält seine Standardschrift). Farbverläufe waren ursprünglich ebenfalls ausgeschlossen; das ist am 09.09.2026 auf Nutzerwunsch zurückgenommen worden ("Mein Vorschlag ein Hintergrundverlauf, wie auf unserer Homepage ... den können wir überall einbauen") - siehe die beiden Verlaufsfarben unten. */ :root { /* Warmes Amber-Orange. Absichtlich von der reinen Markenfarbe #E54B17 (Hue 15) Richtung Hue 27 verschoben, damit weiße Schrift auf Buttons ausreichend Kontrast behält. */ --primary: hsl(27 87% 49%); /* Sehr blasser Primärton - Füllung für "aktiv"-Zustände (z.B. Filter-Umschalter). */ --primary-soft: hsl(27 87% 94%); --secondary: hsl(36 82% 50%); /* Auf Wunsch identisch zur Primärfarbe (per var() verkettet, damit beide nicht auseinanderlaufen). --accent ist sowohl bei BlazorBlueprint als auch an drei Stellen in webshop.css (Belege-Zeile, Lieferadress-Option, Excel-Dropzone) die FLÄCHE für Hover-/ Aktiv-Zustände - mit dem vollen Orange werden diese Flächen entsprechend kräftig. */ --accent: var(--primary); /* Statische Ausgangswerte für die Schrift AUF den drei Markenflächen. Sie gelten nur in Browsern ohne "relative color syntax" - überall sonst werden sie weiter unten durch die automatisch berechnete Variante ersetzt (siehe @supports-Block am Dateiende). */ --primary-foreground: hsl(0 0% 100%); --secondary-foreground: hsl(0 0% 100%); --accent-foreground: hsl(0 0% 100%); --ring: hsl(27 87% 49%); /* Seitenhintergrund: zarte Farbwäsche oben und unten, der Form nach von dedenet.de/dedesales übernommen (dort "bg-gradient-hero-fade"/"bg-gradient-footer-fade") - warm links, kühl rechts, beides sehr blass gegen Weiß auslaufend. Diese beiden Werte sind der Rückfall für Browser OHNE "relative color syntax" und entsprechen exakt den Farben der Website. Überall sonst werden sie am Dateiende aus --primary berechnet, damit ein Farbwechsel den Verlauf mitzieht (Nutzerwunsch 09.09.2026). Ein Customizing kann sie trotzdem einfach überschreiben - dann gilt der eigene Wert, weil ein späteres Stylesheet den @supports-Block hier ebenfalls überstimmt. Wer gar keinen Verlauf will, setzt beide auf die eigene Seitenhintergrundfarbe. */ --verlauf-warm: hsl(38 92% 62%); --verlauf-kalt: hsl(268 55% 78%); /* NEUTRALE, sehr helle Hover-Fläche - bewusst kühl/grau und damit farblos, im Unterschied zum warmen --accent. Verwendet für die Bedienelemente in Header/Footer (Icon-Buttons, Menüeinträge), damit die Kopfzeile beim Überfahren ruhig bleibt und der Orangeton dort allein dem Anmelden-CTA und den Navigations-Unterstrichen vorbehalten bleibt. Inhaltsflächen (Tabellenzeilen, Optionen) nutzen dagegen --accent. Existiert im BlazorBlueprint-Tokensatz nicht. */ --surface: hsl(200 12% 97%); /* Formensprache: große, weiche Radien für Flächen (Karten, Panels, Dropdowns), vollrund für alles Bedienbare (Eingabefelder, Buttons, Badges), kleiner Restradius nur noch für Bilder/Thumbnails (vollrund wäre dort falsch). ACHTUNG: --radius wird zusätzlich von BlazorBlueprints theme.js als Inline-Style auf gesetzt und schlägt diesen Wert nach der Hydration - der Wert hier muss deshalb mit ThemeOptions.DefaultRadius in WebShopApplicationStartup.cs übereinstimmen, sonst springt der Radius beim Laden sichtbar um. */ --radius: 1.25rem; --radius-pill: 9999px; --radius-sm: 0.25rem; --shadow-soft: 0 1px 2px 0 hsl(206 8% 20% / 0.05), 0 1px 3px 0 hsl(206 8% 20% / 0.06); --shadow-card: 0 8px 24px -6px hsl(27 87% 40% / 0.16), 0 3px 10px -3px hsl(27 87% 40% / 0.10); --shadow-elevated: 0 20px 50px -20px hsl(27 87% 49% / 0.35); /* Umschaltpunkt für die automatische Schriftfarbe unten: OKLCH-Helligkeit, ab der eine Fläche als "hell" gilt und deshalb dunkle statt heller Schrift bekommt. Höher stellen = eher weiße Schrift, niedriger = eher schwarze. BEWUSSTE ENTSCHEIDUNG, nicht der rechnerisch optimale Wert: Der rein kontrastbasierte Wendepunkt läge bei etwa 0.62. Die Primärfarbe dieses Themes hat eine Helligkeit von 0.69 und bekäme damit SCHWARZE Schrift - rechnerisch das Optimum (6,91:1 gegenüber 3,04:1 bei Weiß), auf einem Marken-Button aber optisch ungewohnt. Auf Wunsch des Auftraggebers liegt die Schwelle deshalb bei 0.72, sodass kräftige Mitteltöne wie dieses Orange weiße Schrift bekommen. Preis dieser Entscheidung: Weiß auf der aktuellen Primärfarbe erreicht 3,04:1 und bleibt damit unter der WCAG-AA-Anforderung von 4,5:1 für Fließtextgrößen. Wer das später beheben will, muss NICHT diese Schwelle anfassen, sondern die Fläche abdunkeln: ab hsl(27 87% 39%) (#ba5b0d) trägt Weiß 4,58:1 - die Umschaltung liefert dann ohnehin Weiß, ohne dass hier etwas geändert werden müsste. */ --kontrast-schwelle: 0.72; } /* ============================================================================ AUTOMATISCHE SCHRIFTFARBE AUF DEN MARKENFLÄCHEN ---------------------------------------------------------------------------- Damit ein Shop-Betreiber oben gefahrlos beliebige Farben eintragen kann, wird die Schrift auf diesen Flächen nicht fest hinterlegt, sondern aus der Fläche selbst berechnet: helle Fläche -> schwarze Schrift, dunkle Fläche -> weiße Schrift. Ohne das müsste bei jedem Farbwechsel jemand daran denken, auch die drei "-foreground"-Werte nachzuziehen - genau das ging bei der ersten Fassung dieses Themes schief (weiße Schrift blieb stehen, als --accent auf einen sehr hellen Ton wechselte, und war damit praktisch unsichtbar). Funktionsweise: "oklch(from ...)" liest die Helligkeit der Fläche als "l" (0..1). Liegt sie UNTER der Schwelle, wird (schwelle / l - 1) positiv, mal "infinity" also +∞, was clamp() auf 1 begrenzt = Weiß. Liegt sie DARÜBER, wird der Term negativ, also -∞, was clamp() auf 0 begrenzt = Schwarz. Chroma und Farbton werden auf 0 gesetzt, das Ergebnis ist damit immer neutral. Der @supports-Block ist notwendig, nicht nur Vorsicht: Custom Properties nehmen auch Werte an, die ein Browser gar nicht versteht (sie werden erst beim Einsetzen verworfen). Ohne die Abfrage würde ein älterer Browser die statischen Werte oben überschreiben und dann gar keine Schriftfarbe mehr auflösen können. So bleiben dort die statischen Werte stehen. Unterstützt ab Chrome 119 / Safari 16.4 / Firefox 128. ============================================================================ */ @supports (color: oklch(from white l c h)) { :root { --primary-foreground: oklch(from var(--primary) clamp(0, calc((var(--kontrast-schwelle) / l - 1) * infinity), 1) 0 0); --secondary-foreground: oklch(from var(--secondary) clamp(0, calc((var(--kontrast-schwelle) / l - 1) * infinity), 1) 0 0); --accent-foreground: oklch(from var(--accent) clamp(0, calc((var(--kontrast-schwelle) / l - 1) * infinity), 1) 0 0); } } /* ============================================================================ VERLAUFSFARBEN AUS DER PRIMÄRFARBE ---------------------------------------------------------------------------- Nutzerwunsch 09.09.2026: *"kannst du den verlauf aus der primärfarbe ermitteln, so dass bei änderung der primärfarbe per css auch automatisch der verlauf angepasst wird? wenn er dadurch etwas anders aussieht stört das nicht."* Übernommen wird nur der FARBTON der Primärfarbe, mit denselben zwei Abständen, die die Website zwischen ihren beiden Verlaufsfarben hat: +11 Grad für den warmen, +241 Grad für den kühlen Ton. Bei der Standard-Primärfarbe (Hue 27) kommen damit genau die Werte der Website heraus - 38 und 268 - und bei einer anderen Primärfarbe dreht das Paar geschlossen mit. Sättigung und Helligkeit bleiben dagegen FEST. Das ist Absicht: die Wäsche soll blass bleiben, egal wie kräftig oder dunkel die Primärfarbe eines Kunden ist. Würde man sie mitziehen, ergäbe eine satte Primärfarbe einen Hintergrund, auf dem der Inhalt nicht mehr ruhig liegt. Zum @supports-Block gilt dieselbe Begründung wie beim Block darüber: ohne ihn würde ein älterer Browser die statischen Werte überschreiben und dann gar keine Farbe mehr auflösen. ============================================================================ */ @supports (color: hsl(from red h s l)) { :root { --verlauf-warm: hsl(from var(--primary) calc(h + 11) 92% 62%); --verlauf-kalt: hsl(from var(--primary) calc(h + 241) 55% 78%); } }