diff --git a/CLAUDE.md b/CLAUDE.md index e72ae89..ac7eca4 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -13,6 +13,8 @@ die `.user.js`-Datei ist das Produkt. | `dev/index.php` | — | Fixture: Forumwurzel, zwei Kategorien mit Forenzeilen, keine Paginierung | | `dev/ucp.php` | — | Fixture: Login-Formular (`mode=login`), nur ausgeloggter Zustand | | `dev/after_login/ucp.php` | — | Fixture: dieselbe URL nach erfolgreichem Login, "Information"-Vorlage statt Formular | +| `dev/search.php` | — | Fixture: Suchformular ohne Treffer, eingeloggt aufgenommen | +| `dev/search2.php` | — | Fixture: Suchtreffer im Modus "Posts" (15 von 1438 Treffern, `t=63042`, `per_page=15`, 96 Seiten) | Die Fixtures sind ueber `.gitignore` (`dev/*.php`) ausgeschlossen. Nach einem frischen Klon sind sie nicht da und muessen nach der Anleitung in der README neu @@ -203,6 +205,90 @@ Original-Zurueck/Weiter-Links, das Sheet verschwindet. einer verschachtelten Tabelle, `closest('tr')` trifft die innere Zeile ohne Autor- und Profilspalte. +**Die Lupe und die Login-Pille haengen an einer gemeinsamen `margin-left:auto` +auf einem Wrapper (`.rm-auth-group`), nicht je an sich selbst.** Saesse die +Regel wie zuvor direkt auf `.rm-auth`, wuerde nur die Pille an den Rand +geschoben und die Lupe bliebe links davon kleben — mit sichtbarer Luecke +dazwischen statt „direkt links neben der Pille". Die Lupe existiert im Markup +ohnehin nur bei bestehender Sitzung; ausgeloggt bleibt der Wrapper mit der +Pille als einzigem Kind und verhaelt sich exakt wie vorher. + +**`#topic-search` steht dreifach identisch im Thread-Markup** (Kopf, Fuss, +ueber der Beitragsliste), jedes Mal mit derselben, eigentlich unzulaessigen +`id`. `document.querySelector('#topic-search')` trifft einfach das erste und +verschiebt es unveraendert in die zweite Leiste — alle drei tragen dieselben +versteckten Felder (`t`, `sf`, `terms`), welches der drei benutzt wird, ist +gleichgueltig. + +**`select[name="fid[]"]` ist der einzige verlaessliche Marker fuer das grosse +Suchformular auf `search.php`.** Sowohl `viewforum.php` als auch +`viewtopic.php` betten ein eigenes Mini-Suchformular ein (`#forum-search` / +`#topic-search`, „Search this forum…" / „Search this topic…"), beide mit +`action="./search.php"` und einem Feld `name="keywords"` — nach diesen Merkmalen +allein liesse sich das grosse Formular nicht von den kleinen unterscheiden. +Der mehrfach waehlbare Forenwaehler existiert dagegen nur im grossen Formular. + +**Die Textfelder des Suchformulars tragen `style="width: 300px"` direkt im +Markup.** Eine externe Regel ohne `!important` sticht dagegen nicht, egal wie +spezifisch der Selektor ist — `buildSearchForm()` entfernt das +`style`-Attribut deshalb, statt gegen es anzuschreiben. + +**Eine abgeschickte Suche liefert keine Themenliste, sondern einen ganz +anderen Aufbau.** Die anfaengliche Annahme, Trefferzeilen tragen dieselben +`topictitle`-Links wie eine Themenliste und laufen unveraendert durch +`buildList()`, stimmte nicht — zumindest nicht im Modus "Posts" (`sr=posts`), +der ueber die zweite Leiste im Thread entsteht, weil deren Formular kein `sr` +setzt. Jeder Treffer ist stattdessen ein Beitragsauszug: Autor, Zeitstempel, +Forum/Thema-Kontext, ein Stueck `postbody`. `buildSearchResults()` erkennt +diesen Modus an `p.topictitle` — als `

`, nicht als `` wie das +gleichnamige Klassenpendant einer Themenzeile in `viewforum.php` — und baut +daraus eigene Karten (`buildHit()`), bevor `buildList()`s allgemeines +Zeileneinsammeln ueberhaupt anfaengt und die enthaltenen `viewtopic.php`-Links +falsch klassifizieren wuerde. Ungeprueft bleibt der Modus "Topics" (`sr=topics`, +Vorauswahl im grossen Suchformular) — dafuer liegt keine Fixture vor, dort +sehen Treffer laut phpBB-Doku tatsaechlich wie topictitle-Zeilen aus und +wuerden vermutlich durch den regulaeren Listenzweig laufen, das ist aber nicht +verifiziert. + +**Ein Treffer im Modus "Posts" besteht aus drei ``, unterscheidbar nur an +der Position, nicht an einer Klasse.** Titelzeile (`p.topictitle`), Autor- +und Betreffzeile, dann Antworten/Views samt Beitragsauszug — alle drei +tragen row1/row2 wahllos, die einzige verlaessliche Zuordnung ist +`nextElementSibling` von der Titelzeile aus. + +**Der Beitragsauszug haengt in ``, nicht in +`div`/`span.postbody` wie im echten Thread.** `buildHit()` verschiebt das +`` trotzdem unveraendert per `appendChild()` in `.rm-body` — das ist reine +DOM-Manipulation, keine Neuparse, darum meckert der Browser nicht ueber ein +`` ausserhalb einer Tabelle. Es rendert danach aber weiterhin als +`display:table-cell`, wenn `.rm-root.rm-hits .rm-body > td` das nicht +ausdruecklich auf `block` zwingt. + +**"Replies: 5403" und "Views: 951837" stehen im Markup nur durch ein `
` +getrennt, ohne Leerzeichen.** `txt()` normalisiert Whitespace, erzeugt aber +keinen wo im Original-Markup keiner steht — `txt(meta)` liefert deshalb +`5403Views:951837` statt zwei getrennter Werte. `buildHit()` greift beide +Zahlen einzeln per Regex heraus und reicht sie an dieselbe `metaRow()` wie bei +Themenkarten weiter, die den Trenner per CSS (`::before`) selbst einfuegt. + +**`input[type="submit"]`/`input[type="reset"]` setzen eigenes Padding und +Zentrierung in iOS Safari unzuverlaessig um — auch mit `-webkit-appearance: +none`.** Zuerst aufgefallen bei Suchen/Zuruecksetzen im Suchformular +nebeneinander, wo die feste Flex-Aufteilung die Verzerrung besonders sichtbar +machte: zu schmale Buttons, Text nicht mittig. `-webkit-appearance:none` plus +`box-sizing:border-box`/`line-height:normal` (erster Versuch) reichte laut +Test am Geraet nicht aus — das legt einen tieferen WebKit-Bug nahe, bei dem +`input[type=submit/reset]` die native Knopfoptik trotz `appearance:none` nicht +vollstaendig ablegt. Der tragfaehige Fix ist `inputToButton()`: die +Original-``-Elemente werden vor dem Verschieben durch echte +`