Patrick ueber den Support: „Sophie kann Abschnitt 3 und 4 nicht
bestaetigen, beim druecken kommt ein schwarzer Bildschirm."
DER DIALOG WAR DIE GANZE ZEIT DA -- nur nicht im Bild. Nachgebaut auf
einer KOPIE der echten Datenbank, mit einem echten Browser, und dann
gemessen statt vermutet:
position absolute statt fixed
oben im Fenster -143 px also oberhalb des Sichtbaren
`module.css` setzte `.dialog { position: relative }`. Damit war die
Zentrierung des Browsers ueberschrieben: Ein Dialog aus `showModal()`
gehoert mit `position: fixed` in die Mitte des SICHTBAREN FENSTERS,
mit `relative` landet er im Dokumentfluss nahe dem SEITENANFANG. Wer
nach unten gescrollt hatte, sah nur noch den abdunkelnden Schleier --
einen schwarzen Bildschirm.
WARUM AUSGERECHNET „ABSCHNITT 3 UND 4"
Gar nicht wegen dieser beiden. Sophie hatte 1 und 2 schon bestaetigt,
dort gibt es keinen Knopf mehr -- 3 und 4 waren die einzigen, die sie
ueberhaupt noch druecken konnte, und sie stehen am weitesten unten.
Der Fehler hing nie an den Abschnitten, sondern an der Scrollhoehe.
Haette ich die Meldung woertlich genommen und in den Unterweisungen
gesucht, haette ich an der falschen Stelle gegraben.
ES BETRAF JEDEN DIALOG IM HAUS
22 Aufrufe von `showModal()` in 10 Dateien -- vom Loeschen einer Datei
ueber das Bearbeiten einer Aufgabe bis zum Eintragen eines
Monatsziels. Auf kurzen Seiten fiel es nie auf, weil dort niemand
scrollt. Keine einzige Pruefung im Haus hatte je einen Dialog
geoeffnet, NACHDEM sie gescrollt hat.
`relative` stand dort fuer die beiden Pseudo-Elemente (Leuchtschiene
und Lichtsaum) -- die brauchen einen positionierten Vorfahren, und
`fixed` ist ebenfalls einer. `inset: 0` und `margin: auto` schreiben
die Zentrierung jetzt ausdruecklich hin, statt sich auf eine Vorgabe
zu verlassen, die diese Datei selbst ueberschreibt.
WAS ICH FAST KAPUTT GEMACHT HAETTE
Mein erster Entwurf setzte zusaetzlich `max-height` und
`overflow: auto` auf den Dialog. Das waere ein Rueckschritt gewesen:
Das Rollen ist eine Ebene tiefer laengst geloest (`.dialog > form`),
gemessen am 25.09.2026 ueber vier Bildschirmgroessen, nachdem Miss
gemeldet hatte, dass sie aus einem Fenster nicht mehr herauskam. Dort
haengen auch die festen Kopf- und Fusszeilen -- und `position: sticky`
gilt immer zum naechsten rollenden Vorfahren. Ein zweiter Rollbereich
darueber haette genau die wieder geloest. Wieder entfernt;
`mess-dialog-ausgang` meldet unveraendert auf allen vier Groessen
„Kommt man heraus? JA".
NEU: pruef-dialog-sichtbar.mjs (18 Pruefungen, 0 Fehler)
Drei Ebenen, und die unterste allein waere zu wenig:
* Im Quelltext: keine Regel darf `.dialog` wieder aus dem Fenster
nehmen -- in ALLEN Stilvorlagen, nicht nur in module.css.
* Am echten Bildschirm: zwei verschiedene Dialoge auf zwei
verschiedenen Seiten, je auf Computer und Handy, jedes Mal ganz
nach unten gescrollt (663 bis 1216 px).
* Die Gegenprobe: Ein aus dem Fenster geschobener Dialog MUSS
auffallen. Ohne sie waere „er steht im Bild" womoeglich eine
Zeile, die immer wahr ist.
DREI MEINER EIGENEN MESSUNGEN WAREN ZUERST FALSCH, nicht der Code:
Die Textsuche fand Kommentare und `.dialog > *` (die Kinder DUERFEN
relativ sein); die Schulungstabellen entstehen erst beim ersten
Zugriff; und die Auswahl fuer den zweiten Dialog war seit dem
Schnell-Eintrag veraltet -- der erste Knopf oeffnet dort gar keinen
Dialog mehr. Alle drei berichtigt, bevor sie als Befund durchgingen.
NICHT VON MIR, aber beim Nachmessen aufgefallen: pruef-css-klassen
meldet 44 statt 42 Schriftgroessen unter 11,5 px (uebersicht.css,
wissen.css). Meine Aenderung fasst keine einzige Schriftgroesse an --
module.css hat vorher wie nachher denselben Wert. Der Befund ist
aelter und gehoert nicht hierher.
Co-Authored-By: Claude Opus 5 <[email protected]>
170 lines
7.9 KiB
HTML
170 lines
7.9 KiB
HTML
<!doctype html>
|
||
<html lang="de">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
|
||
<title>Support · Spicy & Dogi</title>
|
||
<meta name="robots" content="noindex, nofollow" />
|
||
<link rel="manifest" href="/workspace/app.webmanifest" />
|
||
<meta name="theme-color" content="#06090f" />
|
||
<link rel="icon" type="image/png" href="/assets/img/app-symbole/workspace-32.png?v=202610051932" />
|
||
<link rel="apple-touch-icon" href="/assets/img/app-symbole/workspace-180.png?v=202610051932" />
|
||
<link rel="stylesheet" href="assets/css/gate.css?v=202610051932" />
|
||
<link rel="stylesheet" href="assets/css/start.css?v=202610051932" />
|
||
<link rel="stylesheet" href="assets/css/support.css?v=202610051932" />
|
||
<link rel="stylesheet" href="assets/css/module.css?v=202610051932" />
|
||
<link rel="stylesheet" href="assets/css/haus.css?v=202610051932" />
|
||
</head>
|
||
|
||
<body class="start">
|
||
|
||
<div class="schleier" aria-hidden="true"></div>
|
||
|
||
<header class="kopfleiste">
|
||
<button type="button" class="zurueck-knopf" id="zurueck" hidden>
|
||
<svg class="zurueck-knopf__pfeil" viewBox="0 0 24 24" aria-hidden="true">
|
||
<path d="M14.5 5.5 8 12l6.5 6.5" />
|
||
</svg>
|
||
<span class="zurueck-knopf__text">Zurück</span>
|
||
</button>
|
||
<p class="marke"><span class="marke__text"><a class="zurueck" href="start.html">Creator Workspace</a> · Support</span></p>
|
||
<div class="kopfleiste__rechts">
|
||
<span class="wer" id="wer">…</span>
|
||
<button type="button" class="abmelden" id="abmelden">Abmelden</button>
|
||
</div>
|
||
</header>
|
||
|
||
<!-- `support-seite` (25.09.2026): Filipe wollte fuer diese Kachel
|
||
einen eigenen Stil in Babyblau mit Lila. Die Klasse traegt ihn --
|
||
alle Regeln dazu haengen daran und gelten damit NUR hier. Ohne
|
||
sie muesste man dieselben Farben an dreissig Stellen einzeln
|
||
setzen, und die einunddreissigste waere vergessen. -->
|
||
<main class="inhalt inhalt--breit support-seite">
|
||
|
||
<section class="kopf-zeile">
|
||
<div>
|
||
<p class="marke">Support</p>
|
||
<h1 class="titel" id="seiten-titel">Etwas stimmt nicht?</h1>
|
||
<p class="unterzeile" id="seiten-unter">
|
||
Schreib es hin, häng Bilder dran, fertig. DogFather und die
|
||
rechte Hand kümmern sich darum.
|
||
</p>
|
||
</div>
|
||
</section>
|
||
|
||
<!-- ==================================================================
|
||
ZWEI SEITEN, EINE DATEI (24.09.2026)
|
||
|
||
Filipe: „bei dogfather und der rechten hand soll die kachel
|
||
anders gebaut sein weil die sind die die sich um die probleme
|
||
kümmern."
|
||
|
||
Beide Ansichten stehen hier, und support.js blendet die aus, die
|
||
nicht gilt. Zwei getrennte Dateien wären die naheliegende
|
||
Aufteilung — und die zweite wäre die, in der ein Umbau vergessen
|
||
wird. Dieselbe Entscheidung wie bei hilfe.html.
|
||
|
||
Was der SERVER liefert, entscheidet das ohnehin: Wer nicht zur
|
||
Leitung gehört, bekommt fremde Meldungen gar nicht erst. Das
|
||
Ausblenden hier ist Aufräumen, keine Sicherung.
|
||
================================================================== -->
|
||
|
||
<!-- ---------- MELDEN: sehen und benutzen alle --------------------- -->
|
||
<section class="s-melden" id="melden-block">
|
||
<h2 class="s-titel">Was ist los?</h2>
|
||
<form id="melden" novalidate>
|
||
<label class="s-feld">
|
||
<span class="s-feld__schild">Beschreib es kurz</span>
|
||
<textarea id="text" rows="4" maxlength="2000"
|
||
placeholder="z. B. Auf der Aufgabenseite lässt sich der Haken nicht setzen – der Knopf reagiert nicht."></textarea>
|
||
</label>
|
||
|
||
<!-- ==== BIS ZU DREI BILDER (02.10.2026) ======================
|
||
|
||
Hier stand „EIN BILD, NICHT FÜNF. Wer drei Bildschirmfotos
|
||
anhängt, erklärt damit nichts besser." VanVan hat viermal
|
||
das Gegenteil gemeldet: „Hier im Supportbereich kann man
|
||
immer nur ein Bild hinzufügen bei einer Meldung. 2-3 wären
|
||
besser." Sie ist die, die meldet — ihre Zahl gilt.
|
||
|
||
Und sie hatte recht: Ein Fehler, der aus Vorher, Klick und
|
||
Nachher besteht, braucht drei Bilder. Mit einem davon
|
||
beginnt die Rückfrage, die der ganze Weg sparen soll.
|
||
|
||
`multiple` UND TROTZDEM NACHLEGBAR. Ihr zweiter Satz nennt
|
||
den Fall, den `multiple` allein nicht löst: „wenn man es
|
||
nacheinander versucht hinzuzufügen wird das Bild immer nur
|
||
ersetzt." Das Skript legt deshalb DAZU, statt zu ersetzen
|
||
— eine Mehrfachauswahl auf dem Handy wählt man selten in
|
||
einem Rutsch.
|
||
|
||
WIE VIELE ES SIND, STEHT NICHT HIER. Die Zahl kommt vom
|
||
Server (`bilder_max`); eine zweite im HTML wäre die, die
|
||
beim Ändern vergessen wird. -->
|
||
<div class="s-bild">
|
||
<input type="file" id="bild" accept="image/png,image/jpeg,image/webp,image/gif"
|
||
multiple hidden />
|
||
<!-- MEHRZAHL, SEIT ES MEHRERE SEIN DUERFEN (03.10.2026).
|
||
Hier stand „Bild anhängen" — Einzahl. Die Funktion kann
|
||
seit dem 02.10. drei, nur sagte es niemand: Wer nicht
|
||
zufällig ein zweites Mal tippt, schickt eines. Eine
|
||
Möglichkeit, von der man nichts weiß, gibt es nicht.
|
||
WIE VIELE, STEHT NEBENAN und kommt vom Server — eine
|
||
zweite Zahl hier wäre die, die beim Ändern vergessen
|
||
wird. -->
|
||
<button type="button" class="schritt" id="bild-waehlen">Bilder anhängen</button>
|
||
<span class="s-bild__name" id="bild-name"></span>
|
||
<button type="button" class="schritt" id="bild-weg" hidden>Alle weg</button>
|
||
</div>
|
||
<div class="s-vorschau" id="vorschau" hidden></div>
|
||
|
||
<p class="fehler" id="melden-fehler" role="alert" aria-live="polite"></p>
|
||
<div class="s-knopfreihe">
|
||
<button type="submit" class="knopf" id="senden">Abschicken</button>
|
||
<span class="s-hinweis" id="melden-hinweis"></span>
|
||
</div>
|
||
</form>
|
||
</section>
|
||
|
||
<!-- ---------- MEINE MELDUNGEN: für alle außer der Leitung --------- -->
|
||
<section class="s-meine" id="meine-block" hidden>
|
||
<h2 class="s-titel">Deine Meldungen <span class="s-zahl" id="meine-zahl">0</span></h2>
|
||
<div id="meine-liste" aria-live="polite"></div>
|
||
</section>
|
||
|
||
<!-- ---------- DER EINGANG: nur DogFather und die rechte Hand ------ -->
|
||
<section class="s-eingang" id="eingang-block" hidden>
|
||
<div class="s-eingang__kopf">
|
||
<h2 class="s-titel">Eingang</h2>
|
||
<!-- Die Zahlen stehen VOR der Liste, nicht darunter: Wer
|
||
hereinkommt, will zuerst wissen, ob etwas liegen geblieben
|
||
ist — und erst dann, was genau. -->
|
||
<div class="s-bilanz" id="bilanz"></div>
|
||
</div>
|
||
<div class="s-filter" id="filter" role="group" aria-label="Nach Stand filtern"></div>
|
||
<p class="fehler" id="eingang-fehler" role="alert" aria-live="polite"></p>
|
||
<div id="eingang-liste" aria-live="polite"></div>
|
||
</section>
|
||
|
||
</main>
|
||
|
||
<!-- bereiche.js VOR kopf.js: Dort steht `window.Bereiche`, und
|
||
kopf.js liest daraus die Leitungsrollen. Ohne sie stuerzt jede
|
||
Seite mit der Meldung „Cannot read properties of undefined
|
||
(reading 'LEITUNG')" ab -- gemessen am 24.09.2026, als diese
|
||
Zeile beim Anlegen der Seite fehlte. Die Kopfleiste kam
|
||
trotzdem, deshalb sah man es nur in der Browserkonsole. -->
|
||
<script src="assets/js/bereiche.js?v=202610051932" defer></script>
|
||
<!-- wahl.js gehoert zu kopf.js: Der Sicht-Umschalter in der
|
||
Kopfleiste baut daraus seine Liste. pruef-css-klassen setzt das
|
||
seit dem 07.09.2026 durch -- damals fehlte es auf chat.html und
|
||
uebersicht.html, und heute hier. -->
|
||
<script src="assets/js/wahl.js?v=202610051932" defer></script>
|
||
<script src="assets/js/nachfrage.js?v=202610051932" defer></script>
|
||
<script src="assets/js/installieren.js?v=202610051932" defer></script>
|
||
<script src="assets/js/kopf.js?v=202610051932" defer></script>
|
||
<script src="assets/js/glocke.js?v=202610051932" defer></script>
|
||
<script src="assets/js/support.js?v=202610051932" defer></script>
|
||
</body>
|
||
</html>
|