Centralize status colors and overlay tints into CSS variables #48

Merged

Christoph merged 0 commits from refs/pull/48/head into main

2026-09-18 09:00:29 +00:00

Christoph commented

2026-09-18 08:59:09 +00:00

(Migrated from git.cbsk-tech.de)

What changed (summary of behavior):

Introduces and consolidates variables such as --color-success, --color-danger, --color-warning, --color-info, --color-accent-solid, --color-on-status, and overlay/tint tokens (--app-hover-tint, --app-raise-tint, --app-soft-tint, --app-hairline, --app-active-tint, --app-overlay-shadow, --app-menu-shadow, --app-float-shadow, --app-sunken-tint, etc.).
Replaces repeated hard-coded color values with the new variables across many selectors. Examples visible in the diff:
- .pill-active, .repo-auto-toggle.active, .tb-action.auto-toggle.active, .branch-folder-row.current, .dialog-file-row svg, .prepared-tag, and others now use var(--color-success) instead of #4eca76.
- .status-badge.modified now uses var(--color-warning) instead of #e0a040; deleted/added badges use var(--color-danger)/var(--color-success).
- Hover/raised/soft backgrounds and many component shadows were normalized to use --app-hover-tint, --app-raise-tint, --app-soft-tint and --app-overlay-shadow instead of inline rgba(...) and repeated box-shadow literals.
- Light and dark theme sections provide different concrete values for the same variables so components pick appropriate tints per theme (the file sets the tokens in :root and then overrides/defines theme-specific values later in the file).
A few layout/background variables were simplified for the light theme (e.g. --app-bg, --app-button-bg, --app-input-bg, --app-panel-highlight) and panel/dialog shadows adjusted to use the new shadow tokens.

Why this matters (evidence-based):

The diff shows many duplicate hard-coded color and shadow literals being replaced with a named token; this centralization is intended to make the same semantic colors and overlay behaviors consistent across UI components and to allow different concrete values per theme (light vs dark) while keeping selectors unchanged.

Testing

No test execution results were provided.
Recommended focused checks for reviewers:
1. Visual QA: run the app in both light and dark modes and verify status badges, action toggles, menu hover states, dialogs and overlays render with expected colors/tints and shadows. Pay attention to:
  - status badges (added/modified/deleted/conflicted), repo/action toggle active states, prepared-tag and other success/danger/warning uses.
  - hover/raise/soft overlays on list items, select menus and top-bar buttons to confirm the tint direction is correct for each theme.
2. CSS scan: grep for remaining hard-coded occurrences of the most-frequently replaced hex values (examples):
  - grep -n "#4eca76|#e86060|#e0a040|rgba(255,255,255,0.06)" src || true
    This helps confirm the most common literals are now using variables.
3. Accessibility check: run a contrast checker (or axe) on status text colors against their backgrounds to confirm they meet the intended contrast (there is a comment in the file noting status colours should be above 4.5:1 on their backgrounds).

Compatibility / reviewer notes

The change is purely CSS: no JavaScript or markup changes were introduced in this diff. Reviewers should confirm the chosen token names and concrete light/dark values match design expectations.
If the app needs to support older browsers without CSS variable support, this change increases reliance on custom properties; ensure the build / runtime environment supports them.
No runtime behavior or unit test results were included in the provided evidence; this description is based solely on the diff in src/app.css.

If you review this, please validate the light-mode token values and run a short visual pass on the most common screens (titlebar, repo list, status badges, dialogs, and select menus) to confirm the new tokens produce the intended appearance.

This change centralizes status-related colors and overlay tints into CSS custom properties and replaces many hard-coded color literals and shadow values across src/app.css with those variables. The result is a single set of tokens for status colors (success, danger, warning, info, accent) and a set of overlay/shadow/tint tokens used consistently for both light and dark modes. What changed (summary of behavior): - Introduces and consolidates variables such as --color-success, --color-danger, --color-warning, --color-info, --color-accent-solid, --color-on-status, and overlay/tint tokens (--app-hover-tint, --app-raise-tint, --app-soft-tint, --app-hairline, --app-active-tint, --app-overlay-shadow, --app-menu-shadow, --app-float-shadow, --app-sunken-tint, etc.). - Replaces repeated hard-coded color values with the new variables across many selectors. Examples visible in the diff: - .pill-active, .repo-auto-toggle.active, .tb-action.auto-toggle.active, .branch-folder-row.current, .dialog-file-row svg, .prepared-tag, and others now use var(--color-success) instead of #4eca76. - .status-badge.modified now uses var(--color-warning) instead of #e0a040; deleted/added badges use var(--color-danger)/var(--color-success). - Hover/raised/soft backgrounds and many component shadows were normalized to use --app-hover-tint, --app-raise-tint, --app-soft-tint and --app-overlay-shadow instead of inline rgba(...) and repeated box-shadow literals. - Light and dark theme sections provide different concrete values for the same variables so components pick appropriate tints per theme (the file sets the tokens in :root and then overrides/defines theme-specific values later in the file). - A few layout/background variables were simplified for the light theme (e.g. --app-bg, --app-button-bg, --app-input-bg, --app-panel-highlight) and panel/dialog shadows adjusted to use the new shadow tokens. Why this matters (evidence-based): - The diff shows many duplicate hard-coded color and shadow literals being replaced with a named token; this centralization is intended to make the same semantic colors and overlay behaviors consistent across UI components and to allow different concrete values per theme (light vs dark) while keeping selectors unchanged. Testing - No test execution results were provided. - Recommended focused checks for reviewers: 1) Visual QA: run the app in both light and dark modes and verify status badges, action toggles, menu hover states, dialogs and overlays render with expected colors/tints and shadows. Pay attention to: - status badges (added/modified/deleted/conflicted), repo/action toggle active states, prepared-tag and other success/danger/warning uses. - hover/raise/soft overlays on list items, select menus and top-bar buttons to confirm the tint direction is correct for each theme. 2) CSS scan: grep for remaining hard-coded occurrences of the most-frequently replaced hex values (examples): - grep -n "#4eca76\|#e86060\|#e0a040\|rgba(255,255,255,0.06)" src || true This helps confirm the most common literals are now using variables. 3) Accessibility check: run a contrast checker (or axe) on status text colors against their backgrounds to confirm they meet the intended contrast (there is a comment in the file noting status colours should be above 4.5:1 on their backgrounds). Compatibility / reviewer notes - The change is purely CSS: no JavaScript or markup changes were introduced in this diff. Reviewers should confirm the chosen token names and concrete light/dark values match design expectations. - If the app needs to support older browsers without CSS variable support, this change increases reliance on custom properties; ensure the build / runtime environment supports them. - No runtime behavior or unit test results were included in the provided evidence; this description is based solely on the diff in src/app.css. If you review this, please validate the light-mode token values and run a short visual pass on the most common screens (titlebar, repo list, status badges, dialogs, and select menus) to confirm the new tokens produce the intended appearance.