Der wichtigste Fund: env(safe-area-inset-*) stand bereits im CSS, lieferte
aber immer null -- viewport-fit=cover fehlte auf allen dreizehn Seiten.
Der Code sah richtig aus und tat nichts. Zusammen mit
apple-mobile-web-app-status-bar-style=black-translucent (schon gesetzt)
hiess das: installiert lag die Kopfzeile auf einem iPhone hinter Uhr und
Akkuanzeige.
Behoben:
- viewport-fit=cover auf allen 13 Seiten.
- Vier Sicherheitsabstaende zentral benannt statt an jeder Stelle
einzeln geschrieben. Kopfzeile weicht der Statusleiste, Container dem
seitlichen Notch im Querformat, Fusszeile der Gestenleiste.
- Der 'Ueberspringen'-Knopf des Vorspanns lag mit bottom:2rem praktisch
AUF dem Entsperr-Strich (34px). Man haette die App verlassen statt
uebersprungen.
- Eigener Zweig fuer den installierten Betrieb: kein Gummiband-
Nachfedern (sieht in einer App nach einem Fehler aus), kein
Installations-Hinweis.
- Die vier Sprungmarken auf der Rechtsseite waren 39px hoch -- fuenf
unter dem Daumenmass. Ausgerechnet dort muss man zum Widerrufsrecht
springen koennen.
- 'Waehle links einen Verlauf aus': Auf dem Handy gibt es kein links,
die Liste steht darueber. Richtungswort entfernt.
- Sechs Reiter brauchten auf dem Handy drei Zeilen. Jetzt ein
Wischstreifen mit Einrasten und Auslauf am Rand; der aktive Reiter
wird herangeholt, wenn man ueber eine Kachel springt.
- Uebersicht zweispaltig statt zwoelf Zeilen untereinander: 2635px ->
1924px. Eine Uebersicht, an der man vorbeiwischen muss, ist keine.
Geprueft mit 55 neuen Handy-Pruefungen auf iPhone 14 Pro, Pixel 7 und
320px Breite, jeweils im Browser und im installierten Zweig. Drei
Fehlalarme der eigenen Pruefung wurden begruendet ausgenommen (Honigtopf
bei left:-9999px, Eingabefeld in einer Beschriftung, Inline-Link im
Fliesstext -- WCAG 2.5.8 nimmt letztere ausdruecklich aus).
Zwei Selbstkorrekturen an der Pruefung dokumentiert: Die Emulation von
display-mode wirkt nicht (Chromium nimmt den Befehl an und ignoriert
ihn) -- ohne das waeren die zwoelf 'installiert'-Zeilen ein zweiter
Browser-Durchgang gewesen. Und die Messung gegen die Systemleisten mass
zuerst die Kastenkante statt der Inhaltskante und meldete elf korrekte
Seiten als fehlerhaft. Eine Selbstpruefung mit einem absichtlich falsch
gesetzten Knopf belegt jetzt, dass die Messung echte Fehler findet.
Co-Authored-By: Claude Opus 5 <[email protected]>
Ein 401 ohne Anmeldung beweist nur, dass die Adresse existiert -- nicht,
dass die Antwort auch bei ANGEMELDETEM Zugriff kommt. Genau dort blieb
die Verwaltung stehen.
Die Diagnose geht jetzt denselben Weg wie die Verwaltung: Ausweis von
der Zugangswand holen, damit die Einstellungen abrufen, Zeit messen. Mit
eigenem Zeitlimit von 12 Sekunden, damit die Diagnose nicht selbst
haengt, wenn die Adresse haengt -- ein Pruefwerkzeug, das am selben
Problem scheitert, ist wertlos.
Damit ist der Befund eindeutig statt vermutet: entweder 'Erfolgreich in
X ms', oder eine Statusnummer samt Antworttext, oder 'KEINE Antwort
innerhalb von 12 Sekunden'.
Filipes Diagnose zeigte zwei "!", obwohl alles in Ordnung war:
! Service Worker aktiv -> 1 registriert
! Zwischenspeicher -> dogfather-webdesign-v11
! Anmeldung Verwaltung -> keiner vorhanden
Alle drei sind der NORMALFALL:
Ein aktiver Service Worker ist gewollt -- ohne ihn liesse sich die Seite
nicht als App installieren. Das war ausdruecklicher Wunsch.
Der Zwischenspeicher enthielt v11 -- also genau die Fassung, die der
Server ausliefert. Die erste Fassung meldete JEDEN gefuellten
Zwischenspeicher als auffaellig, auch den topaktuellen. Das ist
Panikmache, kein Befund.
Die Anmeldung gilt je Tab. In einem frisch geoeffneten Tab ist
zwangslaeufig keine da -- und sie SOLL beim Schliessen ohnehin
verschwinden, das war eine ausdrueckliche Vorgabe.
Ein Pruefwerkzeug, das den Normalzustand anmahnt, ist schlimmer als
keines: Es schickt einen auf die Suche nach einem Fehler, den es nicht
gibt -- und wenn dann einmal ein echter kommt, sieht er genauso aus wie
das Rauschen davor.
Jetzt liest die Diagnose die erwartete Fassung aus dem
Service-Worker-Skript auf dem Server und VERGLEICHT. Nur eine
Abweichung ist ein Befund.
GEPRUEFT mit beiden Faellen: bei v11 sechsmal gruen, bei kuenstlich
gesetztem v3 ein "!" mit beiden Fassungsnummern im Klartext.
Co-Authored-By: Claude Opus 5 <[email protected]>
Filipes Screenshot zeigte den Beschreibungstext als schmale
Buchstabensaeule ueber die halbe Seite laufen. Die Ursache ist eindeutig
und mein Fehler:
d.innerHTML = '<span class="mark">✓</span><div><b></b><span></span></div>';
d.querySelector("span").textContent = text;
querySelector liefert den ERSTEN passenden span -- und das war der
Statuskreis, nicht das Textfeld darunter. Der gesamte Beschreibungstext
wurde also in einen 26 Pixel breiten Kreis geschrieben und lief dort
heraus.
Zwei Regeln machten es schlimmer:
.zeile span { ... } traf ebenfalls BEIDE spans
fehlendes min-width:0 verhinderte, dass die Textspalte schrumpfen darf
Jetzt wird die Zeile Element fuer Element aufgebaut, mit direkten
Verweisen statt Suche -- da gibt es nichts zu verwechseln. Die
CSS-Regeln zielen auf eigene Klassen (.inhalt, .text) statt auf den
Elementnamen, der Kreis ist auf feste 26px genagelt und schneidet
ueberzaehligen Inhalt ab, statt die Seite aufzubrechen.
Auch die feste Platzhalterzeile im HTML nutzte noch den alten Aufbau und
haette denselben Fehler gezeigt, sobald sie sichtbar wird.
GEPRUEFT im Browser: alle sechs Zeilen, jeder Kreis exakt 26x26, Text
danebenstehend. Zusaetzlich als Screenshot angesehen -- bei einem
Anzeigefehler ist Messen allein nicht genug, denn genau das hatte die
erste Fassung ja auch bestanden.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung: "garnichts laedt in der verwaltungsseite".
Geprueft statt geraten -- die Serverseite ist in Ordnung:
Dienst aktiv, keine Fehler im Protokoll
CORS-Vorabanfrage 204 mit allow-origin
echte Anfrage 401 (korrekt ohne Anmeldung), Antwortzeit unauffaellig
ausgelieferte Seite enthaelt den neuen Code
Damit bleibt fast nur der Browser: ein alter Service Worker, der
veraltete Dateien ausliefert. Er ueberlebt ein normales Neuladen, und
niemand kann ihn ohne Entwicklerwerkzeuge sehen.
webdesign/diagnose.html prueft sechs Dinge und sagt im Klartext, welches
davon klemmt: Service Worker aktiv? Zwischenspeicher gefuellt? Server
erreichbar und wie schnell? Kennt der Server die neuen Adressen
(404 = Server veraltet)? Liegt eine Anmeldung vor? Und wird die AKTUELLE
Gestaltungsdatei ausgeliefert -- erkennbar an einem Merkmal, das es erst
seit heute gibt.
Ein Knopf meldet den Service Worker ab, loescht die Zwischenspeicher und
laedt die Verwaltung mit Zeitstempel neu. Der Text sagt ausdruecklich,
dass Anmeldung und Daten unberuehrt bleiben -- sonst traut sich niemand
zu klicken.
ZWEI ENTSCHEIDUNGEN
Die Seite laedt KEINE externen Dateien, alles steht inline. Sie muss
funktionieren, wenn genau das kaputt ist, was sie untersucht -- eine
Diagnoseseite, die an derselben veralteten CSS-Datei scheitert, ist
wertlos.
Sie ist von der Zugangswand ausgenommen, wie Widerruf und Rechtstexte.
Gebraucht wird sie genau dann, wenn etwas klemmt; dann darf nicht
ausgerechnet die Zugangswand davorstehen. Sie enthaelt keine Kunden-
oder Projektdaten, sondern prueft nur den eigenen Browser und meldet
Statusnummern.
Co-Authored-By: Claude Opus 5 <[email protected]>
DogFatherGitandClaude Opus 5