Actually center the search box on the nav bar (on desktop) #166
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Grandiras/Ponente#166
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
🤖 On it — follow along in the action run; the reply will link the full session transcript.
📜 Live transcript — updating every ~5 minutes while the task runs.
Pushed
claude/issue-166.What was wrong
The box was the middle item of the header's flex row, which is not the middle of it. The two sides are never the same width — the account side carries the view links, the admin fold and the avatar; the board side carries a name somebody chose — so the box sat 56px right of centre at 1440 and 109px left of it at 1100, drifting with the length of the board's name. That name is the one thing in the header the box is deliberately not about.
The fix
Above 960px both sides take
flex: 1 1 0, so they split the row's leftover in half and the item between the halves lands on the middle. The0basis is the whole trick: withautothe split starts from each side's content width and inherits exactly the difference being cancelled. Still three items in flow, not an absolutely-centred overlay — an overlay would sit on top of a long board name at the widths where the row is already tight..nav-leadneeded amin-width: 13remalongside it. A basis of 0 leaves it no floor at all, and without one the account side's content floor ate the row at 960px and clipped the wordmark mid-letter. Under that floor the search shrinks instead, which is what it did before any of this.The dashed line is the viewport centre, drawn in for the shot:
Measured, at every width
Exactly centred wherever the row can afford a 26rem box between two equal halves. Below that the account side's content floor wins and the box drifts left rather than the nav links wrapping — an off-centre box beats a broken row. Nothing overflows at any width, in either locale, and a 50-character board name still ellipsises without pushing anything. German is the same picture (its wider nav links just move the drift threshold up). Below 960px, where the field is a magnifier, nothing changed.
Verified
dotnet test Ponente.sln— 448 passed, includingDocumentationTests.search.spec.js(3),board.spec.js+filter.spec.js(32),i18n.spec.js,mobile.spec.js— passed against a live app in this container.search.spec.jsfail on the unfixed CSS (checked by stashing the change), so they are pinning the fix and not the weather. They ride the fixture that test already has open: a viewport resize to 1440 for the centring, and one to 960 for the floor and the no-overflow rule.boards.spec.js:165fails here — and fails identically on an unmodified tree. It is the prerender/entrance racedocs/testing.mdalready documents as the reason the e2e suite is not run in a job container. Not filed as an issue, since it is written down.docs/search.mdcarries the reasoning now, including the two prices paid: a long board name runs out of room at half the row rather than at the account's edge (half the row is what centred means), and the box is allowed to drift when the account side genuinely needs more than its half.No changelog line. The search box is itself still in
Changelog.Unreleased— no member has seen the off-centre version, so there is nothing to tell them about.⏱ 20m 13s · 83 turns · tokens: 100.8k in / 42.6k out (+6263.3k cache-read)
📜 Full session transcript
→ Opened PR: #170