Repository navigation
feat(web): add semantic CSS custom-property color layer - #8316
Conversation
Introduce a :root set of semantic color tokens (surfaces, text, borders, accent, state) in global.less and route the recurring, directly-used colors across the LESS files through them. Light-mode values are byte-equal to the literals they replace, so this is a visual no-op; it exists to give a future dark theme a single place to override. Colors that LESS functions (lighten/darken/fadeout) consume, and one-off decorative colors, are intentionally left as literals because those functions cannot operate on var(). Part of mitmproxy#7789.
lups2000
left a comment
lups2000
left a comment
There was a problem hiding this comment.
Thanks for the PR :) Overall, the changes look good to me! 🙌
My only concern is that there are still some border, text, and background colors hardcoded directly in the CSS. Some of them may only be used in one place, so rather than introducing new design tokens for each one, we could potentially reuse existing tokens where appropriate.
For example, I found these:
.command-title {
background-color: var(--mitmweb-bg-alt);
border: 1px solid #aaa;
}
.command-result {
display: block;
margin: 0;
background-color: #fcfcfc;
height: 100px;
max-height: 100px;
overflow: auto;
}
.command-suggestion {
background-color: #9c9c9c;
}These colors look very similar to some of the ones we have already defined.
I assume the main goal of this change is to define the main colors in a single place, which would also make dark mode easier to support.
What do you think? Could you perhaps go through the Less files and check for any remaining hardcoded colors? Thanks :)
Route the remaining directly-used background, text, and border literals across the LESS files through the existing semantic tokens introduced in the color layer, reusing tokens rather than adding new ones. Light-mode colors stay visually unchanged; one-off decorative colors and LESS-function inputs are left as literals.
lups2000
left a comment
lups2000
left a comment
There was a problem hiding this comment.
Just left a couple more nits :) In general, I would like to have as many colors as possible defined in a single place and referenced through var(). This should also make dark mode easier to maintain and review.
We could perhaps leave standard colors such as green or red as literals, but even then, if their values need to change in dark mode, I would introduce a design token for them. Does that make sense?
Add a --mitmweb-highlight token for the shared row-hover / suggestion-selection color (used in header.less and command.less) and a --mitmweb-gray token for the neutral gray reused across mode.less. Remove the unused .command-suggestion rule and the dead rgba() border fallback in dropdown.less, which was overriding the tokenized border and rendering as translucent black.
|
@mhils do you have any thoughts on this? I know you weren’t a big fan of dark mode 😅, but nowadays with AI agents, it might be easier to maintain than it was in the past. This PR is preparing the UI for dark mode. Personally, I would try to centralize the color definitions as much as possible so that we can reference them through tokens. However, some colors are currently used in only one place, so the options seem to be:
Perhaps you have a different approach or other suggestions here :) |
Replace the near-accent literals #428bca (flow detail first line) and #396cad (special tab) with --mitmweb-accent so the accent lives in exactly one place. Both were within a few percent of the token, so this is a small deliberate light-theme shift rather than a visual no-op. The special tab derived its hover from lighten(@special-color, 10%); since LESS functions cannot operate on var(), it now uses --mitmweb-accent-active, the same hover shade .btn-primary already uses.
Add a --mitmweb-green token for the #77c77a left border in mode.less, mirroring the --mitmweb-gray token already used by the neighbouring .gray-left-border.
Add --mitmweb-row-* tokens for the highlighted, selected, and selected+highlighted row shades and route flowtable.less through them. The base rows reuse the existing --mitmweb-bg / --mitmweb-bg-alt surfaces, whose values are byte-equal to the hsl() literals they replace. Values are unchanged, so this is a visual no-op; it gives the dark theme one place to override the row states.
|
Refactored the last hardcoded colors in the |
lups2000
left a comment
lups2000
left a comment
There was a problem hiding this comment.
Nice! LGTM :) There’s just one conflict to resolve. We can either remove the changelog entry and keep only the dark mode one later, or resolve the conflict wth main. You can decide :)
The entry conflicts with the upstream CHANGELOG.md on the PR. Removing it for now; the entry will be re-added once the branch is rebased.
2 participants
Introduces a
:rootset of semantic color tokens and routes recurring colors through them. This is the foundation for the dark theme in the follow-up PR. Colors consumed by LESS functions and one-off decorative colors are intentionally left as literals.Part of #7789.