LLog — Search field: icon overlapping the “Search…” placeholder#

Date: 2026m06d17
Effort: Max (from file, not separately confirmed this session)
Mode: EDEN (from file, not separately confirmed this session)
Model: Claude Opus 4.8 (1M context) — ClaOp48Max
Scope: A small site-wide optical glitch: the search field present on every page shows both a magnifying-glass icon and the “Search…” placeholder, and the two partially overlap. Records the cause, the options weighed, the one-property CSS fix applied, and the visual test.

Note

Append-only audit trail. This is a pure presentation fix in source/_static/custom.css — no content, axiom, theorem, or symbol touched; no .po / translation impact (CSS only).

The prompt (verbatim)#

Can you investigate a small optical glich for me: The Search field on every page has both: a looking glass symbol and “Search” in it, which is fine, except that they partially overlapp. If this is hard to fix, then leave it. But if it’s easy, then make them non-overlapping so it looks cleaner visually. What are the options?

The cause (measured, not guessed)#

The search field is rendered by the theme (pydata-sphinx-theme under sphinx-book-theme), not by our own CSS — custom.css had no search rules before this fix. The markup is a flex form:

<form class="bd-search d-flex align-items-center" …>
  <i class="fa-solid fa-magnifying-glass"></i>      <!-- position:absolute -->
  <input type="search" class="form-control" placeholder="Search…" …>
  <span class="search-button__kbd-shortcut">Ctrl+K</span>   <!-- position:absolute -->

Geometry from the theme + Bootstrap CSS:

  • .bd-search has padding-left:.5rem.

  • The icon is position:absolute; left:calc(1.25rem - .35em) ≈ 0.9rem, and the glyph is ~0.9rem wide, so it occupies roughly 0.9rem → 1.9rem.

  • Both the icon and the Ctrl+K span are position:absolute (removed from flow), so the <input> is the only in-flow flex child: its text box starts at the form’s content edge (.5rem) plus Bootstrap’s .form-control padding-left:.75rem = ~1.25rem.

So the “Search…” placeholder begins at ~1.25rem, inside the icon’s 0.9–1.9rem span — a ~0.55rem overlap. This is width-independent (it is purely a left-edge spacing mismatch), which is why it shows on every page.

Options weighed — EDEN: Green Meadow (count = 3)#

Several presentation fixes each stay reasonable kind gentle OLT; none touches content or meaning, so the field is a Green Meadow. Three diverse bets:

  1. Pad the input so the text clears the icon (chosen). Add left padding to .bd-search input.form-control so the placeholder starts right of the icon. Minimal (one property), keeps the icon as a visual cue, robust to theme updates, and matches the theme’s own physical-left icon placement.

  2. Hide the icon (.bd-search .fa-magnifying-glass{display:none}). Simplest possible; the “Search…” placeholder still names the field, but the icon affordance is lost. Rejected as slightly more lossy than needed.

  3. Reposition / shrink the icon into the left gutter. More fiddly, risks bumping the rounded border, and is more fragile across the 10 languages. Rejected as over-Complication for a one-line problem.

Direction note (the one real cross-language trap): the theme positions the icon with a physical left in all 10 languages — there is no [dir=rtl] flip for .bd-search. So the fix uses physical padding-left, not logical padding-inline-start; logical would pad the right in Arabic/Hebrew and leave the left icon uncovered. Matching physical-with-physical is the non-BABL choice.

Fix applied#

Appended to source/_static/custom.css:

.bd-search input.form-control {
    padding-left: 1.75rem;
}

This moves the placeholder text start to ~0.5rem + 1.75rem ≈ 2.25rem, clearing the icon’s ~1.9rem right edge with a ~0.35rem gap. Specificity (.bd-search + input + .form-control = 0,2,1) and load order (custom CSS after theme) both beat Bootstrap’s .form-control shorthand, so the longhand left padding wins cleanly.

Test (HELD)#

  • make dev build succeeded (23 warnings, all pre-existing); the rule is present in the built build/html/en/_static/custom.css.

  • Visual check via a headless-Chrome screenshot of the built page, cropped/zoomed onto the search box: the magnifying glass and “Search…” are now clearly separated with a comfortable gap, and the ⌘/Ctrl + K shortcut still sits correctly at the right. No overlap. (Screenshots were written under build/ and removed after inspection — not committed.)

The system HELD against the stated glitch: the overlap is gone and the field reads cleanly. (Open-system caveat: tested on the English desktop sidebar at one width; the fix is width-independent and direction-aware by construction, but the RTL languages were reasoned about, not screenshotted.)

Summary & recommendation#

  • Cause: theme/Bootstrap left-edge mismatch — the absolutely-positioned magnifying-glass icon (~0.9–1.9rem) sat over the input’s placeholder start (~1.25rem). Width-independent → appeared on every page.

  • Fix: one CSS property in custom.css — .bd-search input.form-control { padding-left: 1.75rem; }. Physical (not logical) padding on purpose, to match the theme’s physical-left icon in all 10 languages.

  • Status: applied, built, and visually checked on English desktop. Ships on the next push to main.

  • If LLoL prefers a different look: switching to Option 2 (hide the icon) or nudging the 1.75rem value is a one-line change — say the word.

  • Process note: this CSS-only optical tweak is arguably NIL-scope (“throwaway layout experiment / website mechanics”). It was logged in full because the session mode is EDEN and the change ships to production. If LLoL would rather such small visual tweaks run in NIL (no llog), just set the mode.

Prompt 2 (verbatim) — the “two boxes” follow-up (2026m06d17)#

The field looks good. Now I see that there are 2 boxes around the search field (was there before too, but I didn’t see it). Can you make the inner box align with the outer box? (the Outer box is OK, as it visually aligns with the logo. - Don’t try if this is too hard…

Cause#

The theme renders the search box as a .bd-search form that has its own border:1px solid var(--pst-color-border); border-radius:.25rem (the OUTER box, which lines up with the logo width). The <input class="form-control"> inside it also carries Bootstrap’s own border + border-radius + background (the INNER box), inset within the form — hence the box-in-box. The theme CSS has no rule clearing the input’s border/background, so both boxes paint. (This was present all along; the now-cleaner field just made it noticeable.)

Fix#

Extended the same custom.css block (no new selector sprawl):

.bd-search input.form-control {
    padding-left: 1.75rem;      /* prompt-1 fix */
    border: none;               /* drop the inner box */
    background-color: transparent;
    box-shadow: none;           /* no inner ring on focus */
}
.bd-search:focus-within {       /* keep focus visible on the OUTER box */
    border-color: var(--pst-color-link);
    outline: 2px solid var(--pst-color-link);
    outline-offset: 1px;
}

The form already supplies the field background, so dropping the input’s border/background leaves a single clean box (the outer one). box-shadow:none also suppresses Bootstrap’s .form-control:focus ring, which would otherwise re-draw an inner box on focus; specificity (.bd-search input.form-control = 0,2,1) beats .form-control:focus (0,2,0), so no !important is needed. To avoid an accessibility regression (no visible keyboard focus), focus is shown on the OUTER box via :focus-within.

Test (HELD)#

  • make dev rebuilt cleanly (still 23 pre-existing warnings, none new).

  • Headless-Chrome screenshot, zoomed onto the field: the inner box is gone; a single rounded box remains (still aligned with the logo), with the magnifying glass, “Search…”, and the ⌘/Ctrl + K keycaps inside it. (Resting state checked visually; the :focus-within cue was added by construction, not screenshotted, since headless focus is hard to capture.)

Summary#

  • Cause: both the .bd-search form and its Bootstrap <input> draw a border → box-in-box; the theme never clears the input’s.

  • Fix: drop the input’s border + background (+ suppress its focus shadow); move the focus cue to the outer box via :focus-within. One block in custom.css; outer box (logo-aligned) untouched.

  • Status: applied, built, visually checked on the English desktop sidebar. Ships on the next push to main.

  • If LLoL dislikes the focus outline: the :focus-within rule is optional — removing it returns to no focus ring (cleaner, less accessible). One-line change either way.