/* Nur so viel, dass der Admin zur Seite passt – Schrift, Akzent, Schreibfläche, Farbschema. Den Django-Admin nachzubauen wäre Arbeit am falschen Ort: der Betreiber ist eine Person, und jede Zeile hier muss ein Django-Upgrade überleben. Bewusst keine @font-face-Regeln: dieselben 290 KB noch einmal für den Maschinenraum zu laden, zahlt sich nicht aus. Die Schrift greift also nur, wenn sie lokal installiert ist – sonst System-Sans, und das ist in Ordnung. Dass der Betreiber seinen Admin in einer anderen Schrift sieht als seine Leser die Seite, ist ohne Folgen; der Satz entsteht vorn. */ /* Django 5.2 setzt color-scheme selbst (base.css und dark_mode.css, nachgesehen), diese Zeile ändert am Ergebnis also nichts. Sie bleibt, weil sie festhält, was für das ganze Projekt gilt: über hell oder dunkel entscheidet das Betriebssystem. */ :root { color-scheme: light dark; } /* Ueber Djangos eigene Variablen statt ueber eine Liste von Elementen: sie greifen dadurch auch auf Seiten, deren Markup wir nicht kennen. */ :root { --font-family-primary: "Iosevka Aile", ui-sans-serif, system-ui, sans-serif; --font-family-monospace: "Iosevka", ui-monospace, SFMono-Regular, Menlo, monospace; } /* Der Akzent der Seite an Links und am Speicherknopf — in Bernstein, wie vorn. Zwei Dinge sind hier anders als im Frontend, beide aus einem Grund: der Admin kann HELL oder dunkel sein (Djangos eigener Umschalter und data-theme), das Frontend ist immer dunkel. 1. Links brauchen deshalb ein Paar. Nachgerechnet: #7d5200 auf Weiss 6,82:1 und auf Djangos --darkened-bg (#f8f8f8) 6,42:1; #e9a53c auf Djangos dunklem Grund (#121212) 8,84:1 und auf #212121 7,60:1. Hover hebt in beiden Fällen: #5e3d00 auf Weiss 9,80:1, #f7c56f auf #121212 11,75:1. 2. Die Knopffläche bleibt in BEIDEN Modi das dunkle Bernstein. Der Grund ist gemessen: --button-fg ist bei Django weiss, und weisse Schrift auf dem hellen Bernstein #e9a53c erreicht nur 2,12:1 — auf #8a5a00 sind es 5,93:1, im Hover auf #6f4800 8,07:1. Ein Knopf, dessen Fläche zum Seitenhintergrund wechselt, bräuchte dagegen auch eine wechselnde Schriftfarbe, und die hält Django in zehn weiteren Regeln fest. --button-fg bleibt deshalb unangetastet. Der Admin folgt der AKZENT-Umschaltung NICHT: die Klasse dafür sitzt am , und das hält Djangos admin/base.html. Das ist verschmerzbar — den Maschinenraum sieht nur der Betreiber, und die Seite selbst schaltet vollständig um. Djangos Kopfband bleibt absichtlich, wie es ist: --header-bg und --header-link-color faerben nicht nur den Kopf, sondern auch Flaechen im Themen-Auswahlfeld und in den Formularen (forms.css, widgets.css nachgesehen). Sie umzufaerben heisst, Djangos Interna nachzuziehen - und das ueberlebt kein Upgrade. Dass der Maschinenraum anders aussieht als die Seite, ist ohnehin kein Fehler: man weiss immer, wo man ist. */ :root { /* Der einfache Wert zuerst als Rückfall, dann das Paar: so wie bei der Fokusfarbe weiter unten. Fehlt einem Browser light-dark(), gilt der hellere Fall, und Djangos Vorgabe ist hell. */ --link-fg: #7d5200; --link-fg: light-dark(#7d5200, #e9a53c); --link-hover-color: #5e3d00; --link-hover-color: light-dark(#5e3d00, #f7c56f); --link-selected-fg: #7d5200; --link-selected-fg: light-dark(#7d5200, #e9a53c); --button-bg: #8a5a00; --button-hover-bg: #6f4800; --default-button-bg: #8a5a00; --default-button-hover-bg: #6f4800; } /* Die Wortmarke ist ein Link in #site-name und holt ihre Farbe deshalb aus --accent, nicht aus --header-branding-color. --accent umzusetzen faellt aus: dieselbe Variable ist der Hintergrund des heutigen Tages im Kalender (widgets.css), der waere dann weg. Also diese eine Regel. */ #site-name a:link, #site-name a:visited { color: #fff; } /* Die Schreibfläche. Monospace, weil hier Markdown-Quelltext steht und nicht der fertige Satz: Einrückungen von Listen und Codeblöcken sind nur in gleichen Vorbreiten zu sehen. */ .qp-schreibfeld { font-family: "Iosevka", ui-monospace, SFMono-Regular, Menlo, monospace; font-size: 15px; line-height: 1.6; tab-size: 4; resize: vertical; padding: 16px; /* width und min-height sind hier Pflicht, nicht Geschmack – und der Grund ist im Browser nachgesehen: "field-sizing: content" lässt den Browser die Attribute rows und cols ignorieren und das Feld nach seinem Inhalt bemessen. Bei einem NEUEN Essay ist der leer, und das Feld kollabierte zu einem Kästchen von etwa zwanzig Pixeln. Djangos eigene Breitenregel (admin/css/forms.css: .vLargeTextField { width: 48em }) fängt das nicht auf, weil SchreibFeld die Klasse bewusst ersetzt. */ width: 100%; max-width: 78ch; /* dasselbe Zeilenmaß wie im Zieltext */ min-height: 816px; /* Rückfall: 34 Zeilen à 1,6 × 15px */ min-height: 34lh; /* dasselbe, aber an der echten Zeilenhöhe */ field-sizing: content; /* wächst darüber hinaus mit dem Text */ } /* Der Akzent der Seite an der einen Stelle, an der er im Admin etwas leistet. Der helle Wert steht als Rückfall zuerst und trägt allein, wo light-dark() fehlt. Warum hier light-dark() und vorn in quiet.css eine Media Query: der Admin hat mit Djangos Umschalter ein zweites Hell/Dunkel, das per data-theme am hängt und die Media Query überstimmt. light-dark() folgt dem gerechneten color-scheme und damit beiden Wegen. Gerechnet mit der WCAG-2.x-Formel (SC 1.4.11 fordert 3:1): #7d5200 auf dem weissen Feld 6,82:1, #e9a53c auf Djangos dunklem Feldgrund #2b2b2b 6,68:1. */ .qp-schreibfeld:focus { outline: 2px solid #7d5200; outline-color: light-dark(#7d5200, #e9a53c); outline-offset: 2px; }