2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	a06184f24f	Der Name auf der Teamseite hatte null Pixel -- und drei Messungen waren stumpf ... Weiter am Rundumcheck, diesmal der Handy-Rundgang. Von sechs Befunden war einer ein echter Layoutfehler, zwei waren zu kleine Schrift, und drei kamen daher, dass die Messung etwas nicht unterscheiden konnte. === AUF DEM HANDY KAPUTT === 1. DER NAME IN DER PERSONENKARTE WAR NULL PIXEL BREIT. Gemessen auf 412 px: `h3.tperson__name` mit `w=0` bzw. `w=15`. Der Name stand als Buchstabensaeule da oder gar nicht -- auf der Seite, die von Menschen handelt. `.tperson__text` trug `flex: 1; min-width: 0`. Das erlaubt dem Textblock, auf null zu schrumpfen, und Flexbox schrumpft lieber, als umzubrechen -- die Pille „zuletzt gesehen" daneben blieb stehen und nahm allen Platz. `min-width: 0` war trotzdem richtig gemeint (ohne sie blaeht ein langes Wort den Kasten auf); es fehlte nur die Untergrenze. Jetzt `min(14ch, 100%)`: vierzehn Zeichen, wenn so viel Platz ist, sonst der ganze Platz, der da ist. Die Pille bricht um -- `flex-wrap: wrap` stand am Kopf ohnehin schon, es fehlte nur der Grund, es zu benutzen. 2. ZWEI BESCHRIFTUNGEN UNTER DER LESBARKEITSGRENZE. `.u-weg__marke` 10,88 px, `.u-weg__aus` 11,2 px -- die Hausgrenze sind 11,5. Der Reflex dahinter: Eine Marke soll leise sein, also macht man sie klein. Leise wird sie aber durch Farbe und Gewicht; eine Schrift, die man nicht lesen kann, ist nicht leise, sondern weg. Derselbe Griff ist mir gestern dreimal an einem Tag passiert. === DREI MESSUNGEN, DIE ETWAS NICHT UNTERSCHEIDEN KONNTEN === 3. `pointer-events: none` IST KEIN BERUEHRZIEL. Die Terminpunkte im Monatsraster des Kalenders sind 8 x 8 px und nehmen ausdruecklich keine Beruehrung an -- angetippt wird die ZELLE. Sie als „zu klein" zu melden ist, als beanstande man die Groesse eines gemalten Knopfs. `pruef-breiten` kennt die Ausnahme seit jeher; im Handy-Rundgang hat sie gefehlt. 4. `font-size: 0` IST KEINE KLEINE SCHRIFT, SONDERN KEINE. Dieselben Punkte: Die Schrift wird auf null gesetzt, die Farbe bleibt. Gemeldet wurde „0px, zu klein". Die Grenze nach unten bleibt scharf -- alles zwischen 0,1 und 11,5 px ist weiterhin ein Befund, nur die glatte Null faellt heraus. Sie ist eine Aussage, keine Nachlaessigkeit. 5. `scrollWidth > clientWidth` SAGT BEI INLINE-ELEMENTEN NICHTS. Chromium liefert dort fuer `clientWidth` glatt null, und damit ist jeder Text breiter als sein Kasten. Der richtige Umgang mit einer unmoeglichen Messung ist, sie nicht zu machen -- nicht, ihr Ergebnis zu glauben. Dazu: Was per `clip-path: inset(50%)` fuer das Auge weggenommen ist (echte <select> unter selbst gebauten Umschaltern, Beschriftungen zu Symbolknoepfen), kann nicht abgeschnitten sein. === UND EINE MELDUNG, DIE JETZT SAGT, WO MAN SUCHEN MUSS === „abgeschnitten: Mara (18>0)" hat mich zwanzig Minuten gekostet -- drei Vermutungen, drei Messungen. Die Meldung nennt jetzt Element, Klasse, Darstellungsart und Breite: „Mara (18>0, h3.tperson__name, block, w=0)". Damit war der Fall in einem Blick klar. Eine Pruefung, die nur sagt DASS etwas ist, ist eine halbe. GEMESSEN: pruef-breiten 0 Fehler (9 Breiten, 38 Seiten), pruef-team 51/0, pruef-tippziele 11/0, pruef-css-klassen 33/0. Im Handy-Rundgang bleiben die Kopfleisten-Befunde bei 360/390/412 px -- die nehme ich mir als Naechstes vor, sie brauchen einen Umbau und keine Korrektur. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-25 13:27:01 +02:00
DogFatherGitandClaude Opus 5	f7276172d0	Drei Fehlalarme, die auf echte Stellen zeigten -- und keiner war ein Fehler ... Weiter am Rundumcheck. Diese Runde hat KEINE Zeile am Programm geaendert: Alle drei Befunde kamen aus den Pruefungen selbst. Das ist kein Trost, sondern die unangenehmere Sorte -- ein Fehlalarm nennt eine echte Stelle und eine plausible Zahl, und man sucht danach am richtigen Code. 1. EIN FARBFORMAT, DAS DIE MESSUNG NICHT KANNTE. `pruef-neue-seiten` meldete auf treff-regeln.html einen Kontrast von 1,07 -- praktisch unsichtbarer Text. Nachgemessen an Ort und Stelle: dunkler Text auf HELLBLAUER Flaeche, rund 10:1. Chromium gibt eine Farbe, die aus `color-mix()` entstanden ist, als `color(srgb 0.37 0.78 0.97)` zurueck -- Werte von 0 bis 1, keine Kommas. Die Messung las nur `rgba?(...)`, fand die Flaeche des Sprunglinks nicht, ging zum fast schwarzen Elternteil weiter und rechnete dunkel gegen dunkel. Im Haus ist `color-mix` ueberall. Der Farbleser kennt jetzt beide Formate und faehrt vier Proben mit (rgb, rgba, color(srgb), color(srgb / alpha)) -- dazu eine fuenfte, die beweist, dass er bei Unbekanntem NICHTS liefert. Ein Leser, der im Zweifel Schwarz zurueckgibt, waere schlimmer als der alte: Er wuerde nie wieder auffallen. 2. EINE SEITE, DIE ZU KURZ WAR, UM "GEFUELLT" ZU HEISSEN. Dieselbe Pruefung verlangte von jeder Seite mehr als 400 Zeichen Text. entwicklung.html hat 350 -- seit dem Umbau, bei dem aus achtzehn Zahlenkaesten zwei Personenkacheln mit einem Ring wurden. Die Seite sagt seither mehr und braucht weniger Worte; die Pruefung bestrafte damit genau die Verbesserung. Jede Seite darf jetzt sagen, woran man sieht, dass sie da ist: eine Zeichenzahl, wo Text die Sache ist -- ein MERKMAL (".e-person", mindestens zwei), wo Struktur die Sache ist. Eine Zahl kann beides nicht unterscheiden. 3. EIN ABSCHNITT, DER SPAETER KAM ALS DIE MESSUNG. "Die rechte Hand sieht ihre eigene Karte" war rot -- versteckt, obwohl der Server `hat_karte: true` sagte. Von Hand nachgesehen stand sie da. Die Entwicklungsseite laedt nacheinander (Aufgaben, Vorlagenbrett, eigene Karte), und zwischen zwei Schritten kann es laenger als 600 ms still sein -- die Ruheregel der Pruefung hielt das fuer "fertig". Jetzt wartet sie zusaetzlich auf den einen Abschnitt, der sich selbst aufdeckt, hoechstens zwei Sekunden. Nebenwirkung: Der Vergleich "zwei verschiedene Bildschirme" misst jetzt 632 gegen 1191 Zeichen statt 350 gegen 350. 109 Pruefungen, 0 Fehler (vorher 8). 4. UND EINE FESTE ZAHL, DIE MIT DER SEITE GEWACHSEN IST. `pruef-buehne` erlaubte hoechstens ZWEI Texte, um die herum kein freier Untergrund zu finden ist. treff-regeln.html hat inzwischen 40 Textstuecke, drei davon stehen dicht -- 7,5 %. Die Sorge dahinter bleibt richtig (eine Pruefung, die kaum hingesehen hat, darf nicht "bestanden" sagen), aber das ist eine Frage des ANTEILS: zwei von vier waere schlimm, drei von vierzig ist es nicht. Jetzt: zwei immer erlaubt, darueber ein Zehntel -- und die Meldung nennt die Textanfaenge, damit man in einer Sekunde sieht, worum es geht. ZWEI NEUE WERKZEUGE, beide aus der Not dieser Runde entstanden: mess-farbe-am-text.mjs -- liest die Farben an Ort und Stelle aus und geht die Elternkette hoch bis zur ersten deckenden Flaeche mess-seiteninhalt.mjs -- zeigt, was auf einer Seite wirklich steht, mit ROLLE=hand auch mit fremden Augen GEMESSEN: pruef-neue-seiten 109/0, pruef-buehne alles in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-25 12:48:16 +02:00