LLog — Nav-bar caret direction: match the footer (up=closed, down=open)#

Date: 2026m06d18
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: The primary-sidebar (nav-bar) collapse caret pointed the opposite
way from the footer dropdown carets. Flip the nav caret so both follow one
convention: point UP when closed, DOWN when open. Sibling to the search-field
work in b40
(same session, different component → separate entry).

Note

Append-only audit trail. Pure presentation fix in source/_static/custom.css — no content, axiom, theorem, or symbol touched; CSS only, no .po / translation impact. The footer was not modified (it was already correct); only the nav caret changed.

The prompt (verbatim)#

While your’re at such formalities: It’s been bothering me for some time that the > “triangle” associated with the up and down in the NAV BAR is going the opposite way form how it’s defined to open or close the boxes in the footer. Can you make both such that they do what the footer does? (I.e. point upwards when closed and downwards when open)

The cause (both sides measured)#

Two different components, two different icon systems, drawn in opposite directions:

Footer dropdowns (the reference — already correct). The FF footer boxes are sphinx-design <details class="sd-dropdown"> using an octicon .sd-summary-chevron-right (a right-pointing “>” glyph). custom.css already carried a footer override:

closed: transform: rotate(-90deg) → “>” becomes “^” = UP
open: transform: rotate(90deg) → “>” becomes “v” = DOWN

So the footer is up=closed, down=open — matching both the user’s description and the code.

Nav-bar caret (the one going the wrong way). The primary sidebar’s collapsible items are <details> whose summary holds a FontAwesome .fa-chevron-down (a “v” glyph). The theme styled it:

closed (base): no transform → “v” = DOWN
open: .bd-sidebar-primary li.has-children>details[open]>summary .fa-chevron-down { transform: rotate(180deg) } → “^” = UP

So the nav was down=closed, up=open — exactly the opposite of the footer.

EDEN: Green Meadow (count = 3)#

Several presentation-only ways to flip the nav caret; all stay reasonable kind gentle OLT and touch no content. Three diverse bets:

Rotate the existing ``.fa-chevron-down`` (chosen): rotate 180° when closed, 0° when open. Minimal, reuses the theme’s own icon, animates with the theme’s transition. Same selector shape as the theme + custom.css loads after it, so source order wins (no !important needed).
Swap the glyph (e.g. force fa-chevron-up when closed via CSS content / a different icon class). More moving parts; fights FontAwesome’s glyph mapping. Rejected as over-Complication.
Restyle with a custom SVG/octicon to literally match the footer’s glyph. Most “consistent” at the pixel level but heaviest and most fragile across theme updates. Rejected as over-Reach for a rotation problem.

Fix applied#

Added next to the footer caret block in source/_static/custom.css:

.bd-sidebar-primary li.has-children > details > summary .fa-chevron-down {
    transform: rotate(180deg);   /* closed → point up */
}
.bd-sidebar-primary li.has-children > details[open] > summary .fa-chevron-down {
    transform: rotate(0deg);     /* open → point down */
}

Specificity note: the closed rule (0,3,3) is unopposed at the closed state (the theme sets no transform there); the open rule (0,4,3) ties the theme’s open rule and wins on source order. No !important needed (unlike the footer, which had to beat sphinx-design’s own [open] rule). Covers every collapsible level (toctree-l0 captions and nested has-children items).

Test (HELD)#

make dev rebuilt cleanly (23 pre-existing warnings, none new); the rule is present in build/html/en/_static/custom.css.
Headless-Chrome screenshot of solution/index.html (one open branch + closed siblings), nav sidebar cropped: every closed item (Buy In, The Crisis, The Challenge, The Choice, The Jubilee System…) shows the caret pointing UP; the open item (“The Solution”, current page) shows it pointing DOWN with its child revealed. Matches the footer convention.
Footer left unchanged and not re-screenshotted: it is doubly confirmed (existing rotate(-90deg)/rotate(90deg) override + user’s own description) and my selectors do not touch it.

The system HELD: the nav caret now reads up=closed / down=open, consistent with the footer. (Open-system caveat: checked on the English desktop sidebar; the rule is language-independent — it rotates the same icon the theme already places in every language.)

Summary & recommendation#

Cause: two icon systems drawn opposite ways — footer octicon chevron-right (already rotated to up=closed/down=open) vs nav FontAwesome fa-chevron-down (theme default down=closed/up=open).
Fix: rotate the nav .fa-chevron-down 180° closed / 0° open, in custom.css beside the footer caret block. Footer untouched.
Status: applied, built, visually checked on the English desktop sidebar. Ships on the next push to main.
Not in scope (flag for later, if wanted): in-content .. dropdown:: boxes and admonition toggles elsewhere on the site still use the sphinx-design default (right=closed, down=open) — a third convention. The user asked only about nav-bar vs footer; making every caret site-wide identical would be a separate, larger sweep. Say the word if you want it.