Claude: changes for issue #177 #178

Merged
Grandiras merged 1 commit from claude/issue-177 into main 2026-08-27 02:56:03 +00:00
Collaborator

Closes #177.

Closes #177.
Make the compact search a flyout, and its trigger read as a button
All checks were successful
CI / build (pull_request) Successful in 33s
55a27dd29a
Below 960px the search box opened as a full-screen mode: the field at the
top of an otherwise blank page, with the board it is searching gone. Eight
rows of results is a flyout's worth of content and not a page's, so most of
what covered the board was empty, and a takeover is a heavier promise than
"look something up" — the only way back was one word in a corner.

It is now a flyout under the header, right-aligned to the window rather than
hung off its trigger: what sits between the trigger and the window's edge is
the two view links and the admin fold, so a 26rem panel anchored to the
trigger starts at -146px in a 620px window. Anchored to the window it always
fits and the trigger is always inside its span, which is what `.nav-admin-menu`
beside it already does.

On a phone that flyout is a sheet standing on the bar — the shape of the two
menus beside it, and the sheet rule in docs/ui.md rather than an exception to
it. The magnifier stays lit under the sheet, so a second tap on the same spot
is the way out, and the board above stays visible. Its field is at the bottom
of the sheet with the results growing upward: a sheet is anchored at its
bottom edge, so with the field on top every result that arrives shoves the box
being typed into a couple of hundred pixels away from the thumb, mid-word.
Only the rows swap; the markup still reads field then list.

The keyboard had to be measured for that, because no CSS describes it: the
sheet is fixed to the layout viewport and an on-screen keyboard shrinks only
the visual one, so the field would be drawn underneath the thing it is typed
on. search-interop.js watches visualViewport and publishes --keyboard-inset;
unset, the sheet is simply on the bar. It is also why the phone keeps the word
in the corner — with the keyboard up the trigger is behind one.

And the trigger wears a surface now. A bare glyph between a board name and a
face in a pill reads as a label for the row, not the third thing in it you can
press; it takes `.nav-menu-toggle`'s box and grows to 46x40, 52x44 on the bar,
with the mark at 20px.

No changelog entry: the search box itself is still in Unreleased, so this
changes a shape no member has seen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Author
Collaborator

🤖 Reviewing this PR — follow along in the action run; the reply will link the full session transcript.

📜 Live transcript — updating every ~5 minutes while the task runs.

🤖 Reviewing this PR — follow along in [the action run](https://git.grandiras.net/Grandiras/claude-bot/actions/runs/406); the reply will link the full session transcript. <!-- claude-run:pr_review --> 📜 [Live transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/pr-178/run-406.md) — updating every ~5 minutes while the task runs.
claude-reviewer left a comment

✅ Verdict: approve — no blocking issues found.

Went through the CSS grid/flex mechanics, the fixed-position anchoring math for the tablet flyout and the phone sheet, the --keyboard-inset visualViewport plumbing in search-interop.js, and the z-index/stacking-context interactions with .nav-menu-backdrop and the other bottom-bar sheets — everything lines up. The markup in SearchBox.razor is untouched except comments (confirmed against the current DOM order: mark, input, clear, close, panel), so the field-at-bottom/list-above swap on phones is purely the grid-area reassignment described in the docs, and screen-reader order is preserved as claimed. The tablet flyout's right-anchored position: fixed box correctly picks up the existing .nav-search-panel (position: absolute; left:0; right:0) as its dropdown without any new CSS needed, since it's a descendant of the now-fixed field. The keyboard-inset fallback (var(--keyboard-inset, 0px)) matches the JS behavior of only ever setting the property once watch() runs, and clearing it in unwatch(). New Playwright coverage (flyout bounds test at 620px, sheet-seated-on-bar/shadow/field-position assertions at 390px) matches the shapes described. Docs (search.md, ui.md, frontend.md) were updated in step with the code, as required. No correctness issues found.


⏱ 2m 7s · 9 turns · tokens: 51.2k in / 10.6k out (+567.2k cache-read)
📜 Full session transcript

✅ **Verdict: approve** — no blocking issues found. Went through the CSS grid/flex mechanics, the fixed-position anchoring math for the tablet flyout and the phone sheet, the `--keyboard-inset` visualViewport plumbing in `search-interop.js`, and the z-index/stacking-context interactions with `.nav-menu-backdrop` and the other bottom-bar sheets — everything lines up. The markup in `SearchBox.razor` is untouched except comments (confirmed against the current DOM order: mark, input, clear, close, panel), so the field-at-bottom/list-above swap on phones is purely the grid-area reassignment described in the docs, and screen-reader order is preserved as claimed. The tablet flyout's right-anchored `position: fixed` box correctly picks up the existing `.nav-search-panel` (`position: absolute; left:0; right:0`) as its dropdown without any new CSS needed, since it's a descendant of the now-fixed field. The keyboard-inset fallback (`var(--keyboard-inset, 0px)`) matches the JS behavior of only ever setting the property once `watch()` runs, and clearing it in `unwatch()`. New Playwright coverage (flyout bounds test at 620px, sheet-seated-on-bar/shadow/field-position assertions at 390px) matches the shapes described. Docs (`search.md`, `ui.md`, `frontend.md`) were updated in step with the code, as required. No correctness issues found. --- ⏱ 2m 7s · 9 turns · tokens: 51.2k in / 10.6k out (+567.2k cache-read) 📜 [Full session transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/pr-178/run-406.md) <!-- claude-verdict:approve --> <!-- claude-reviewed-head:55a27dd29a99c206bb52267c6ccc8a3d9f57b85c -->
Grandiras deleted branch claude/issue-177 2026-08-27 02:56:03 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Grandiras/Ponente!178
No description provided.