Repository navigation
Primer branding: fix undefined --fg-default color token - #330
Merged
pelikhan merged 1 commit intoOct 14, 2026
Merged
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
pelikhan
marked this pull request as ready for review
October 14, 2026 05:00
pelikhan
deleted the
primer-branding/fix-undefined-fg-token-4039c9283c19b254
branch
October 14, 2026 05:00
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
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.
What changed
Color
.btn-evalsreferencedcolor: var(--fg-default), but--fg-defaultis never defined in either the light (:root) or dark ([data-color-mode="dark"]) theme blocks insrc/styles/style.css, and the declaration had no fallback value. Per CSS custom-property semantics, an undefined var with no fallback makes the wholecolordeclaration invalid at computed-value time, so the property is treated as unset and silently inherits frombody { color: var(--text-primary); }instead. Visually this currently "works by accident," but it violates token consistency — every other button variant in the file (.btn-primary,.btn-assistant,.copy-modal-action, etc.) resolves its text color through an explicitly defined custom property..btn-evalsat the already-defined--text-primarytoken (the same semantic role used bybodyand other neutral-text elements), which is the correct source-of-truth token for default foreground text in this codebase's token system.Guidance that motivated this change
The brand audit instructions call out, as a priority deviation category: "hard-coded hex values that should use Primer CSS variables or brand tokens" and more broadly, consistent token usage across light/dark mode. While
--fg-defaultisn't a hard-coded hex, it's an undefined/invented token reference with the same root problem — it doesn't trace back to any defined design token in the project's palette (which otherwise closely mirrors Primer's functional color roles such as--brand-color-text-default/--brand-color-text-mutedfrom theprimer-brandMCP token set:var(--brand-color-text-default) = var(--base-color-scale-black-0)).Audit findings not changed (and why)
--bg-primary,--text-primary,--accent-blue, label colors, etc.) is a deliberate, cohesive brand-adjacent system layered on top of@primer/css, not raw ad-hoc hex sprinkled arbitrarily. I verified contrast ratios for the main text/background and label-badge combinations (all ≥ 4.5:1, most 5–13:1), so no accessibility-contrast issues were found that needed fixing.--color-success-fg,--color-danger-fg,--color-attention-fg,--color-prettylights-syntax-*, and--borderRadius-medium/largeare also "undefined" in this file, but each of those appears only as the fallback argument insidevar(--token, fallback)(e.g.var(--success, #1a7f37)), which is valid, intentional, and safe — they are not bugs, so I left them untouched to keep the change set minimal.Validation
npm test— 329 tests passed (19 test files), no regressions.npx vite build— production bundle built successfully (36.67 kB CSS, 61.75 kB JS, no errors). Note: the repo'sprebuildnpm script (npm run build) also runsscripts/fetch-vendor-assets.mjs, which requires outbound npm registry access to vendor@primer/css; that step fails in this sandboxed environment with an unrelated 403 (network policy), not because of anything in this change — the underlying Vite build itself completes cleanly.Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
registry.npmjs.orgTo allow these domains, add them to the
network.allowedlist in your workflow frontmatter:See Network Configuration for more information.