fix(header): switch active topic nav from blue accent to grayscale#15
Closed
hongyi-chen wants to merge 1 commit intomainfrom
Closed
fix(header): switch active topic nav from blue accent to grayscale#15hongyi-chen wants to merge 1 commit intomainfrom
hongyi-chen wants to merge 1 commit intomainfrom
Conversation
The active topic tab in the docs header (e.g. "Terminal") rendered with pale blue text and a 2px pale blue underline because both pulled from `--sl-color-text-accent`. Per Warp brand guidelines flagged in internal review, the top nav should match the sidebar's neutral grayscale active treatment instead. Switch the `a[aria-current='page']` text color and the 2px underline indicator to `--sl-color-white`. That token is theme-aware (off-white in dark, near-black in light) and is the same color used by the sidebar's selected row in `warp-components.css` §1, so the two navigation surfaces now share one grayscale "selected" visual language. Comments above each rule are updated to reflect the new design intent. The Scalar-style underline anchor (replacing the header hairline under the active tab) is preserved; only the color changes. Co-Authored-By: Oz <oz-agent@warp.dev>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Collaborator
Author
|
Closing — this PR retoned the wrong surface (top topic nav). The actual asks are about the Search / Ask / Copy chrome buttons, which is being addressed in a follow-up PR on a fresh branch. |
hongyi-chen
added a commit
that referenced
this pull request
May 5, 2026
…rey (#17) * fix(chrome): retone Search / Ask / Copy buttons to warp.dev neutral grey The shared --warp-control-* palette was sourced from the Oz webapp brand ladder (gray-700/800/900 = #414651/#252b37/#181d27), which carries ~11–24% blue saturation. Against the neutral #121212 docs canvas this read as visibly cool/blue chips on Search, Ask, and Copy. Repoint the palette to the warp.dev marketing brand neutrals (--color-neutral-* in warp-marketing-site-static/.../global.css) so the trio reads as one grayscale chrome family instead of blue stickers floating on neutral page bg. Body prose tokens (--sl-color-gray-*) intentionally stay on the Oz ladder; only the chrome controls move. Light-mode surface tokens (gray-100/200/300) are already neutral and kept; the higher-tier hover/text/icon entries swap to the warp.dev neutrals for consistency. Fallback literals in kapa.css and CopyPageButton.astro are updated in lockstep so the chrome can't drift if var() ever falls back. Top topic nav (Terminal / Agents / Reference) is intentionally untouched — replaces the misdirected #15. Co-Authored-By: Oz <oz-agent@warp.dev> * fix(search-dialog): retone Pagefind modal to warp.dev neutral grey (#18) * fix(search-dialog): retone Pagefind modal to warp.dev neutral grey The Pagefind search modal still shipped Starlight's default chrome, which paints: - the dialog frame in --sl-color-gray-6 / gray-5 (Oz cool blue grays #252b37 / #414651), - the input focus ring in --sl-color-accent (Warp blue), - result hover/focus in --sl-color-accent-high outlines and --sl-color-accent-low fills, - cancel + clear buttons in --sl-color-text-accent (blue). On the neutral #121212 canvas + the warp.dev grayscale chrome system this all reads visibly cool/blue and out of family with the trigger button it just opened from. Add a new §18 in warp-components.css with unlayered overrides scoped to `site-search dialog` (so the Kapa Ask dialog stays untouched): - dialog surface → --sl-color-bg + hairline border (one-canvas pattern, depth from backdrop blur), - backdrop overlay → flat neutral scrim per theme, - --pagefind-ui-* custom props pointed at --warp-control-* so all of Pagefind's internal surfaces inherit the new palette, - input :focus border → --warp-control-border-hover (no blue ring), - cancel + clear buttons → calm gray-2 / gray-3, - result cards + tags → --warp-control-bg with a hairline, - hover/focus-within → --warp-control-bg-hover wash + matching border, no blue accent outline. Stacked on top of #17 (chrome trigger retoning). Co-Authored-By: Oz <oz-agent@warp.dev> * fix(chrome): unify control corner radius to 4px across chrome family Chrome corner radii were inconsistent across adjacent surfaces: - Search trigger / Ask / Copy trigger: 4px (sm) ✓ - Search modal input + clear + tag chips: 8px (Pagefind default) - Search modal result cards: 5px (Starlight --sl-search-corners) - Copy dropdown items: 6px (md) - Kapa form input + submit: 6px (md) Establish one rule for the chrome family: - Every clickable control surface (button, single-line input, list/menu row, kbd chip, toast) → --sl-radius-sm (4px) - Every floating overlay (dialog, dropdown panel, popover, chat bubble) → --sl-radius-lg (8px) - Content cards (code blocks, asides, file tree) keep their --sl-radius-md (6px) — content surface, not chrome. Changes: - warp-components.css §18: override Pagefind's --pagefind-ui-border-radius and Starlight's --sl-search-corners to --sl-radius-sm so the search input, clear button, tag chips, and result cards all land at 4px. - CopyPageButton.astro: dropdown items 6px → 4px (panel keeps 8px). - KapaChatLauncher.css: .sl-kapa-form input + .sl-kapa-submit 6px → 4px (matching the chrome trigger they pair with). Co-Authored-By: Oz <oz-agent@warp.dev> --------- Co-authored-by: Oz <oz-agent@warp.dev> --------- Co-authored-by: Oz <oz-agent@warp.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
In the docs site header, the active topic tab (e.g. Terminal) renders with pale blue text and a 2px pale blue underline. The sidebar's active page uses a neutral grayscale highlight instead, so the two "selected" treatments don't match. Per Warp brand guidelines flagged in internal review, the top nav should be grayscale.
Root cause
In
src/components/WarpTopicNav.astrothe active state pulls from--sl-color-text-accentfor both the text color and the 2px underline. That token resolves tohsl(217, 90%, 84%)in dark mode (pale blue) andhsl(207, 80%, 40%)in light mode (saturated blue) — defined insrc/styles/custom.css.Fix
Switch the two
a[aria-current='page']rules to--sl-color-white(theme-aware: off-white in dark, near-black in light). That's the same token the sidebar's selected row uses inwarp-components.css§1, so the two navigation surfaces now share one grayscale "selected" visual language. The Scalar-style underline anchor (replacing the header hairline under the active tab) is preserved; only the color changes. Inline comments above both rules are updated to reflect the new design intent.The
--warp-control-*chrome tokens used by Search/Ask are intentionally cool-gray per the Oz brand ladder and are left untouched.Validation
npm run buildsucceeds (309 pages built, no test suite perAGENTS.md).Conversation: https://staging.warp.dev/conversation/48c5a764-39e4-43a1-9da0-8a7cff67ed3d
Run: https://oz.staging.warp.dev/runs/019de56f-115d-77ac-beb4-ddd0d3b816dd
Plans:
This PR was generated with Oz.