From 7ccf904c3cd26d48903e160c62bc70cf092920e5 Mon Sep 17 00:00:00 2001 From: Dogfather Date: Tue, 22 Sep 2026 14:58:45 +0200 Subject: [PATCH] Das Aufgaben-Formular: was aufklappt, bekommt jetzt auch Platz MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Filipe, 22.09.2026, zum Bildschirmfoto: „wie scheisse sieht das aus, verbesser das bitte." Zu sehen: „Anlegen" und „Abbrechen" lagen mitten in der Personenliste. GEMESSEN statt geraten, bei 1280 px mit aufgeklappter Liste: Zelle Zeilen Hoehe Inhalt feld-verant 24px 44px 68 107 feld-mehrere 43px 44px 87 261 <-- 174 zu viel Jede Zelle des Formularrasters bekommt zwei Zeilen: Beschriftung oben, Eingabe unten mit festen 44 px. Das ist richtig und der Grund, warum alle Eingaben auf einer Linie sitzen (17.09.). `feld-mehrere` ist aber keine Beschriftung mit Eingabe, sondern ein Knopf mit einer Liste, die aufklappt. Ihr zweites Kind landet in der 44-Pixel-Zeile und laeuft heraus, sobald jemand sie oeffnet. Was herauslaeuft, belegt keinen Platz -- also legt es sich ueber das Naechste, und das Naechste sind die Knoepfe. DIE MESSUNG HAT MICH VOR DEM NAHELIEGENDEN FEHLER BEWAHRT. Erster Gedanke: „Zellen ohne eigene Eingabe brauchen die zwei Zeilen nicht" -- `:has(> input, > select, > textarea)`. Die Messung sagt etwas anderes: Von sieben Zellen haben SECHS ihre Eingabe nicht als direktes Kind, weil der Auswahl-Baustein sie in ein
wickelt. Die Regel haette fast das ganze Formular getroffen und genau die Ausrichtung zerstoert, die sie schuetzen soll. `aria-expanded` ist gemessen das einzige Merkmal, das nur bei dieser Zelle steht -- und es ist das inhaltlich richtige: Es sagt „dieser Bereich kann groesser werden". Etwas, das groesser werden kann, darf keine feste Hoehe haben. UND DIE PRUEFUNG, DIE ES HAETTE FINDEN MUESSEN pruef-formulare war gruen -- sie klappt das Feld nie auf. Ein Zustand, der nie hergestellt wird, kann nicht gemessen werden. Neuer Abschnitt: Jedes Element mit `aria-expanded` im Formular wird geoeffnet, danach darf keine Rasterzelle mehr Inhalt haben, als sie hoch ist. Nicht diese eine Stelle, sondern die Eigenschaft -- damit faellt auch die naechste auf, die es noch gar nicht gibt. ZWEI ANLAEUFE DABEI WAREN FALSCH, und der zweite war der gefaehrliche: 1. `scrollHeight` der Zelle meldete elf Zellen als kaputt, die alle in Ordnung sind: Der Hinweis unter einem Feld haengt seit dem 17.09. absichtlich absolut darunter. Eine Warnung, die bei richtigem Verhalten anschlaegt, wird abgeschaltet. 2. Nur die direkten Kinder im Fluss -- das war gruen, AUCH MIT DEM ECHTEN FEHLER. Nachgemessen mit zurueckgenommener Behebung: immer noch gruen. Das Raster staucht das Kind auf die feste Zeilenhoehe, das Kind bleibt also brav in der Zelle; was herauslaeuft, ist der Inhalt darin. Jetzt misst sie in die Tiefe (ohne Teilbaeume unter absolut gesetzten Elementen und ohne eigene Rollbereiche) und ist beidseitig belegt: mit Behebung -> gruen ohne Behebung -> FEHL „feld-mehrere: Inhalt reicht bis 169 px, Zelle ist 87 px hoch" Dazu eine Gegenprobe, die eine Zelle kuenstlich einklemmt. Ueberlappungen im Formular: von 12 auf 4 -- und die vier sind Absicht (der echte