2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	10a075cc33	Gestaltung: Hoehensystem -- mehrschichtige Schatten und Lichtkante ... Bis hierher trug jede Karte EINEN Schatten. Das ist solide und genau der Grund, warum eine Oberflaeche "ordentlich" statt "teuer" wirkt. Echtes Licht erzeugt zwei Dinge gleichzeitig: einen engen, dunklen Kontaktschatten an der Kante -- er sagt dem Auge, dass etwas AUFLIEGT -- und einen weiten, weichen Umgebungsschatten, der sagt, wie HOCH es darueber schwebt. Nur einen von beiden zu setzen sieht aus wie ein Aufkleber; beide zusammen ergeben einen Gegenstand. Dazu die LICHTKANTE: eine 1 Pixel hohe, sehr schwache weisse Linie an der Oberkante. Sie tut so, als kaeme das Licht von oben und braeche sich an der Kante. Das ist das meistuebersehene Detail in dunklen Oberflaechen und dasjenige mit der groessten Wirkung -- ohne sie wirkt eine Karte wie ein Loch im Hintergrund, mit ihr wie ein Stueck Material. Drei Stufen, mehr braucht es nicht: ruhende Flaechen, hervorgehobene Flaechen, Schwebendes. Dazu eine vierte, umgekehrte fuer Eingabefelder: Die liegen nicht AUF der Flaeche, sie sind hineingeschnitten -- oben dunkel, unten hell. Weil es die gemeinsamen Bausteine sind, wirkt es sofort auf allen 13 Seiten: Hauptseite, Portal und Verwaltung. Dazu Feinheiten, die einzeln niemand bemerkt und in Summe den Unterschied machen: Uebergaenge auf 160-180 ms verkuerzt (alles darueber wirkt beim Ueberfahren traege), eigene Rueckmeldung beim Druecken, optische Laufweitenkorrektur fuer grosse Ueberschriften (-.028em bei h1; das Auge sieht bei 48px mehr Weissraum zwischen Buchstaben als bei 16px), text-wrap: balance gegen einzelne Woerter in der letzten Zeile. EIN FEHLER BEIM EINBAU, GEMESSEN STATT UEBERSEHEN Nach dem ersten Durchgang hatten die Karten ihre Lichtkante, der Hauptknopf nicht. Grund: Die Grundregel lautet ".wd .wd-btn--haupt, .wd-btn--haupt" -- der erste Teil zaehlt ZWEI Klassen. Mein Nachtrag zaehlte eine und verlor, obwohl er spaeter steht. Dieselbe Falle wie am 22.08.2026 bei ".wd a" gegen ".wd-btn--haupt". Aufgefallen nur, weil die Pruefung die Lichtkanten ZAEHLT. PRUEFWERKZEUGE ANGEPASST diagnose.html ist jetzt ausgenommen. Sie traegt bewusst alles fest in sich -- eigene Farben, keine Uebersetzung -- weil sie funktionieren muss, wenn genau das kaputt ist, was sie untersucht. Sie an den Regeln der eigentlichen Seite zu messen erzeugte zwei Meldungen, die man auf Dauer wegsieht. Und irgendwann sieht man dann auch eine echte weg. ALLES GRUEN: Gestaltung 0 Befunde (12 Seiten x 5 Sprachen gegen WCAG 2.2 AA), Designsystem 5, Verwaltung 69, Portal 32. Versionsstempel und Cache auf v17. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 18:37:17 +02:00
DogFatherGitandClaude Opus 5	be3599239d	Designsystem: eine Quelle je Farbe, Radien auf eine Skala ... Diese Runde ging eine Ebene tiefer als "sieht es gut aus": Ist das System, aus dem das Aussehen entsteht, ueberhaupt eines? DIE MESSUNG VORWEG Markenfarben ausgeschrieben im Quelltext: 155 Stellen davon Blau 74, Gold 33, Lila 22, Gruen 16, Rot 10 verschiedene Eckenradien: 12 darunter 5px, 7px, 9px, 11px Die Farben gab es laengst als Variablen. Sie standen trotzdem ueberall ausgeschrieben da, weil halbdurchsichtige Toene -- Raender, Leuchten, sanfte Flaechen -- einen Alphawert brauchen, und das mit einer fertigen Farbvariablen nicht geht: rgba(127, 208, 232, .16). Die Folge waere beim ersten Farbwechsel sichtbar geworden: Man findet 150 Stellen, uebersieht fuenf, und die Seite hat danach zwei Blautoene, die sich um eine Nuance unterscheiden. Genau das ist der Unterschied zwischen einer gewachsenen und einer gestalteten Oberflaeche. WAS GEAENDERT WURDE Kanalvariablen (--wd-blau-rgb: 127 208 232) neben den fertigen Farben. Damit schreibt man rgb(var(--wd-blau-rgb) / .16), und eine Aenderung wirkt ueberall. 164 Stellen umgestellt, verteilt ueber CSS und neun Seiten. Auch die abgeleiteten Farben zeigen jetzt auf die Kanaele statt eigene Werte zu fuehren -- und die vier Prozessfarben (--wd-p1 bis p4) sind keine eigenen Farben mehr, sondern Rollen: --wd-p1: var(--wd-blau). Sonst haette man vier weitere Stellen, die beim naechsten Farbwechsel stillschweigend zurueckbleiben. Ergebnis: Jede Markenfarbe hat genau EINE Quelle. Ausgeschriebene Markenfarben im Quelltext: 0. Radien auf vier Stufen plus Pillenform: 6 / 10 / 14 / 20 / 999. Kein Wert wurde um mehr als 2px verschoben, optisch aendert sich also nichts Spuerbares -- 12 verschiedene Werte sind auf 3 tatsaechlich verwendete zusammengeschmolzen. Zwischenwerte wie 7px oder 11px entstehen nicht aus Absicht, sondern weil man beim Bauen einer neuen Kachel nicht nachschaut, was nebenan schon gilt. DER BEWEIS, DASS ES EIN SYSTEM IST Neue Pruefung pruef-system.mjs. Sie behauptet nicht, sie STELLT UM: Die Markenfarbe wird von Babyblau auf kraeftiges Orange gesetzt und dann nachgezaehlt, ob irgendwo der alte Ton stehen bleibt. 658 von 1975 sichtbaren Elementen tragen die Markenfarbe 0 bleiben nach der Umstellung beim alten Ton Prozessfarben folgen nachweislich mit Radien: 3 Stufen UND DIE WICHTIGSTE ERKENNTNIS -- ueber das Messen selbst Der erste Anlauf meldete 110 haengengebliebene Elemente, alle in Kopf- und Fusszeile. Die naheliegende Erklaerung waere gewesen: "da steht die Farbe noch ausgeschrieben". Sie war falsch. Nachgewiesen ueber die DevTools-Schnittstelle: Auf diese Elemente wirkt die Regel ".wd a:not(.wd-btn) -> var(--wd-blau)", und --wd-blau resolviert an genau dieser Stelle korrekt zum neuen Orange. Trotzdem blieb die berechnete Textfarbe alt -- auch nach erzwungener Neuberechnung. Der Unterschied: Kopf- und Fusszeile werden von wd-core.js per innerHTML eingefuegt. Chromium erneuert solche Teilbaeume nicht zuverlaessig, wenn man eine Variable NACHTRAEGLICH umstellt. Laedt man dieselbe Seite mit bereits geaenderter Variable, sind sie orange -- gegengeprueft mit einem Minimalbeispiel, in dem derselbe Mechanismus einwandfrei funktioniert. Das Pruefverfahren wurde deshalb umgestellt: Die Variable wird VOR dem Laden ueberschrieben. Das entspricht genau dem, was eine Aenderung in der CSS-Datei bewirkt -- also dem Fall, um den es wirklich geht. Haette ich der ersten Messung geglaubt, haette ich 110 einwandfreie Stellen "repariert" und dabei das gerade aufgebaute System wieder zerlegt. Es ist der siebte Fehlalarm in eigener Messtechnik innerhalb von zwei Runden -- und der subtilste. ALLE PRUEFUNGEN GRUEN: Gestaltung 0 Befunde (13 Seiten x 5 Sprachen gegen WCAG 2.2 AA), Anfragedetail 20, Verwaltung 69, Portal 32, Widerruf 58, Textkodierung 55 Kombinationen, Designsystem 5. Versionsstempel und Cache-Name auf v9. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 13:05:12 +02:00