DogFatherGitandClaude Opus 5
a06184f24f
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]>
