05ea7036551c6e4b2bb031ef11406887fe2e4c68
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
7225ae052e |
Fassung 1.5.2: die Optionen selbst
Drei Bedienungen, die Flatsome an jeder Option hat und die hier fehlten. Geraeteschalter je Option. Bisher entschied ein einziger Schalter ueber der Vorschau, welches Geraet das ganze Bedienfeld bearbeitet; "ist die Ueberschrift auf dem Telefon kleiner" liess sich nur durch Umschalten und Hinsehen beantworten. Jetzt traegt jede Option drei Chips (D, T, M): sie zeigen, wo ein eigener Wert liegt, und ein Klick wechselt dorthin. Bedienfeld und Vorschau wechseln gemeinsam - einen Wert fuer ein Geraet zu setzen, das man nicht ansieht, ist blindes Aendern. Abstand als Rahmen. Vier Felder untereinander, beschriftet "Oben, Rechts, Unten, Links", zwangen zum Lesen. Jetzt sitzt jedes Feld an seiner Kante, die Lage ist die Beschriftung; in der Mitte verkettet ein Schalter alle vier. Er startet aus: er ersetzt den frueheren Knopf "Alle Seiten gleich setzen", und das war eine bewusste Handlung. Seiten mit unterschiedlichen Einheiten gelten als "gemischt" und bleiben unangetastet - ein gespeichertes 2rem wird nicht still zu 2px. Ziehfelder. Zahlenfelder lassen sich seitwaerts ziehen, Umschalt grob, Alt fein. Tippen und Pfeiltasten bleiben unveraendert. Nur fuer Maus und Stift: auf einem Tippgeraet ist ein seitliches Ziehen ueber ein Feld die Art, wie das Bedienfeld gescrollt wird. Dabei behoben: der Zug war nach einem Pixel zu Ende, weil jede Aenderung das Bedienfeld neu zeichnete und damit das Feld ersetzte, an dem der Zeiger hing (keepPanel). Der Kettenschalter verlor aus demselben Grund seinen Zustand. Und das Gleichziehen nahm den Wert des ersten Feldes, auch wenn es leer war - ein Druck auf die Kette loeschte damit die Seiten, die einen Wert hatten. Geprueft: npm test 27/27, phpunit 452/452, npm run test:editor vollstaendig mit neuem Abschnitt und ohne axe-Verstoss. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
67b85751cf |
Randlose Abschnitte, volle Bildschirmhoehe, Vollbild-Hero
Umuts Frage: "Haben wir bilder usw als volles bild startseite? 100% hoehe usw?" Die Teile gab es, die Kombination nicht - und zwei Sachen fehlten wirklich. Abschnittsbreiten: neu "randlos" (ohne Begrenzung, ohne Rand, von Kante zu Kante) und "breit" (1600 px) neben normal und schmal. Vorher war jeder Inhalt auf 1180 px begrenzt; ein Bild von Kante zu Kante war nicht moeglich. Hoeheneinheiten: neu dvh, svh, lvh. 100vh ist auf dem Handy hoeher als der Bildschirm - es meint die Ansicht ohne Adressleiste, und der untere Rand verschwindet darunter. 100dvh ist das, was jemand meint, der "volle Hoehe" sagt. Und eine Vorlage "Vollbild-Hero", die die ganze Kombination auf einen Klick setzt: randlos, 100dvh (mobil 80dvh), Inhalt senkrecht zentriert, Hintergrundbild formatfuellend, dunkle Ueberlagerung damit der Text lesbar bleibt, Ueberschrift, Text, Button. Die Teile waren alle da, aber diese Kombination zu finden war eine Recherche. 328 PHP-Tests / 1329 Assertions, 17 JS-Modelltests. Geprueft: vier Breiten angenommen und eine erfundene abgewiesen, sieben Hoehenangaben mit dvh/svh/lvh und zwei ungueltige, ein randloser Abschnitt mit formatfuellendem Bild, und die Hero-Vorlage Eigenschaft fuer Eigenschaft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
464f52b147 |
Suchfeld im Designbereich, Sicherung als Arbeitspaket O
Neunzig Eigenschaften in acht zugeklappten Gruppen: "wo ist die Rahmenstaerke" ist eine berechtigte Frage. Jetzt filtert ein Suchfeld die Eigenschaften, oeffnet die passenden Gruppen und sagt, wie viele Treffer es gibt - und wenn keine, wo eigenes CSS zu finden ist. Getestet: "rahmen" laesst die Gruppen Rahmen und Bild stehen, 14 Treffer. Neu im Ausbauplan, Paket O: Sicherung und Wiederherstellung als Funktion statt als Disziplin. Heute entstehen Sicherungen nur als Nebenprodukt des Updaters und weil ich vor jeder Migration von Hand eine Kopie lege. Geplant sind Datenbank per VACUUM INTO statt copy (eine Kopie waehrend eines Schreibvorgangs kann unbrauchbar sein), Medienordner, ein Manifest mit Fassung, Migrationsstand und Pruefsummen - und ohne .env, weil darin APP_SECRET steht und eine Sicherung den Server verlaesst. Dazu Rotation, damit die Platte nicht vollaeuft und die naechste Sicherung nicht genau dann scheitert, wenn man sie braucht. Die Abnahme ist die Wiederherstellung, nicht die Sicherung: eine Seite loeschen, zurueckspielen, pruefen dass sie wieder da ist. Eine Sicherungsfunktion, deren Wiederherstellung nie gelaufen ist, ist eine Vermutung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
7251b82f09 |
Designer: 93 Eigenschaften, neun Einblendungen, drei neue Bausteine
Umut fragte nach Zeilen, nach Rahmen und Rundungen - und ob der Designer so aufgestellt ist wie Flatsome. Der Vergleich steht in docs/DESIGNER-VERGLEICH.md, mit der Einschraenkung, dass Flatsome hier nicht installierbar war: das ist Wissen, keine Messung. Zwei echte Fehler kamen dabei heraus, beide vorher unbemerkt. Eine Rahmenstaerke je Seite wurde zu border-width-top. Das ist kein CSS, der Browser verwirft die Zeile stillschweigend - Rahmenstaerken je Seite hatten nie eine Wirkung, und es gab keine Meldung, die darauf hingewiesen haette. Die Schreibweise steht jetzt je Eigenschaft im Schema, weil padding-top dem Namen folgt und border-top-width nicht. Und eine Rundung auf einem Bildblock landete auf dem figure, waehrend das Bild darin eckig blieb. Eigenschaften koennen jetzt auf das Bild im Block zielen (target 'img' im Schema, eine zweite Regel im Compiler) - deshalb tut object-fit ueberhaupt etwas, denn auf einem figure tut es nichts. Von 50 auf 93 Eigenschaften: Bild (Ausschnitt, Bildmitte, Seitenverhaeltnis, Hoehe, Ecken, Rahmen), Positionierung mit z-index, getrennte Zeilen- und Spaltenabstaende, Flex je Element, Innen- und Textschatten, acht Bildfilter als eine filter-Deklaration in fester Reihenfolge, Mischmodus, Zusatzrahmen, Mauszeiger. Neun Einblendungen mit Verzoegerung, sieben Hover-Effekte, alle innerhalb von prefers-reduced-motion. Drei neue Bausteine (Dokumentschema v15): Symbol als eigenes Element, Fortschritt mit role=meter und dem Wert im Markup statt nur in der Balkenbreite, und ein Slider als Scrollbereich mit Einrasten - ohne JavaScript, ohne Autoplay, mit Finger, Trackpad, Mausrad und Tastatur. Zeilen waren nicht unauffindbar, sondern unbrauchbar leer: eine Zeile ohne Spalten sieht aus wie nichts. Jetzt legt "Zeile, 2/3/4 Spalten" beides auf einen Klick an, und im Werkzeugkasten steht, wie der Aufbau gemeint ist. 315 PHP-Tests / 1309 Assertions, 16 JS-Modelltests, axe auf dreizehn Bildschirmen ohne Verstoesse. 16 Datensaetze rechnen jede Eigenschaftsform gegen die erwartete Deklaration nach - die Pruefung, die die beiden Fehler oben gefunden haette, wenn es sie vorher gegeben haette. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
ba56add678 |
Browsertests wiederhergestellt; drei echte Fehler gefunden
Der Playwright-Editortest war durch den Editorumbau kaputt: er steuerte die abgeschafften Auswahllisten. Umgeschrieben auf die freien Bedienelemente - Einheitenfelder, Vererbung über drei Geräte, einzelnes Zurücksetzen, Palettenfarbe, Abstand je Seite, Hover-Regel, freie Rasterspalten und die weiter vorhandenen Bewegungseffekte. Dabei kamen drei Fehler heraus, die ohne Browserlauf unsichtbar sind: 1. Die frei gestalteten Werte wirkten in der Editorvorschau gar nicht. Ein srcdoc-Iframe erbt die Richtlinie des einbettenden Dokuments, und die Verwaltung verbietet Inline-Styles - das erzeugte style-Element wurde stillschweigend verworfen. Ausgeliefert wurde es korrekt, nur die Vorschau log. Jetzt als inertes template plus adoptedStyleSheets. 2. Die Einrückung der Unterseiten in der Seitenliste hat nie funktioniert; sie lief über ein style-Attribut, das dieselbe Richtlinie verwirft. Jetzt über Klassen. 3. Das Theme setzte alle Links auf die Akzentfarbe und überschrieb die kontextabhängigen Farben: 3,08:1 auf dunklem Grund. Die Regel gilt jetzt nur für Links in Textblöcken, die voreingestellte Linkfarbe liegt auf allen hellen Tönen über 4,5:1. Geprüft: 155 PHP-Tests / 579 Assertions unter PHP 8.2.12 und 8.4.22, 15 JavaScript-Modelltests, vollständiger Editortest mit axe (null Verstöße) und Lighthouse 13.4.1 mit je drei Läufen mobil und Desktop, alle fünf Kategorien 100. Offen: npm run test:browser schlägt wegen eines Inhalts fehl - /grundlagen trägt einen im Editor gesetzten Textblock mit 2,75:1. Nicht verändert, weil es eine Nutzerentscheidung ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
270cbda9ac |
Direktbearbeitung, Kontrastwarnung und Gestaltungsvorlagen
Inline-Textbearbeitung ohne Skript in der Vorschau: der Iframe führt weiterhin kein eigenes JavaScript aus, der Editor greift in sein Dokument und setzt das Element auf contenteditable. Während der Bearbeitung wird die Vorschau nicht neu geladen, sonst wäre der Cursor weg; Eingaben werden zu einem Undo-Schritt zusammengefasst. Neben dem Doppelklick startet eine Schaltfläche dasselbe ohne Maus. Kontrast wird nach WCAG 2.1 berechnet und als Warnung in drei Stufen gemeldet, nicht als Verbot - der Plan verlangt Prüfung, nicht Bevormundung. Gestaltungsvorlagen liegen im Theme und gelten seitenübergreifend. Sie werden mit demselben Compiler geprüft wie ein Blockstil, also kann über diesen Weg kein Wert hereinkommen, für den ein Block abgewiesen würde. Dazu Kopieren und Einfügen zwischen Blöcken und Bildauswahl für Hintergrundbilder über die Mediathek. Geprüft: 155 PHP-Tests / 579 Assertions unter PHP 8.2.12 und 8.4.22, 15 JavaScript-Modelltests, Lint/Format/Container. Erstmals wurde der neue Editor im laufenden Betrieb bedient: Direktbearbeitung und Kontrastwarnung mit echten Werten ausgelöst, Teständerungen verworfen. Weiterhin keine axe- oder Lighthouse-Messung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
abf0bd2c6b |
Freie Gestaltung statt Tokenlisten (Dokumentschema v10)
Der bisherige Editor bot drei Farben, keine Schriftwahl und elf Auswahllisten mit 44 festen Werten. ADR 008 hatte das mit Sicherheit begründet - der Schluss war falsch: die Alternative zu beliebigem CSS-Text ist nicht eine Auswahlliste, sondern ein typisiertes Designmodell. StyleSchema erklärt jede Eigenschaft einmal mit Typ, CSS-Entsprechung und Grenzen. Validator, CSS-Erzeugung und Editorpanel lesen dieselbe Definition, also kann der Editor nichts anbieten, was der Server ablehnt. Rund fünfzig Eigenschaften in sieben Gruppen, je Block, je Gerät und für den Hover-Zustand, mit Vererbung und einzelnem Zurücksetzen. Werte sind kurze Zeichenketten mit verankertem Muster, nie CSS-Text; zusammengesetzte Deklarationen baut der Compiler selbst. Der Server erzeugt daraus pro Seite ein blockgenaues Stylesheet, das über seinen eigenen SHA-256-Hash erlaubt wird statt über unsafe-inline. Theme unter /admin/theme: freie Farbpalette als @schlüssel, Schriften aus Systemschrift oder Google Fonts, Grundtypografie mit modularer Überschriftenskala. Google Fonts auf ausdrückliche Nutzerentscheidung; die Richtlinie öffnet die Hosts nur, wenn wirklich eine eingestellt ist. Alte Tokenwerte aus v2 bis v9 bleiben gültig und im Editor unter "Klassische Werte dieser Seite" bearbeitbar. Geprüft: 154 PHP-Tests / 563 Assertions unter PHP 8.2.12 und 8.4.22, 15 JavaScript-Modelltests, Lint/Format/Container. Im Browser wurde nur der Aufbau des Panels bestätigt, kein Gestaltungsvorgang von Hand ausgeführt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |