Pr/theme customisation - #690
Open
2xburnt wants to merge 6 commits into
Open
Conversation
@ping-pub/widget bundles its own Tailwind + daisyUI build and injects it into the document at runtime. That stylesheet re-declares [data-theme=light] and [data-theme=dark]; because it lands after the app's stylesheet and has equal specificity (0,1,0), it wins. Any value customised in `daisyui.themes` is therefore silently discarded in the browser. It goes unnoticed here because the widget is built from this repo's own theme, so the two agree. It breaks immediately for anyone re-theming a fork: their config is correct, the CSS is emitted correctly, and the browser still paints ping.pub's colours. Reproduced by setting dark `base-100` to #123456: before --b1 resolves to 224 29% 23% (the widget's value) after --b1 resolves to 210 65% 20% (the configured value) This duplicates each daisyUI theme rule with an `html` prefix, raising it to (0,1,1). Values are copied verbatim by PostCSS rather than recomputed, so where the app and widget already agree the output is byte-identical and there is no visual change. The original rule is kept, so element-level theming (`<div data-theme="...">`) still works.
…literal Four places hardcode #666CFF, which is the same value `daisyui.themes` already sets as `primary`. Duplicating it means a project that changes primary in the config still gets #666CFF in these spots. Routed through the theme instead. CSS contexts use hsl(var(--p)); the SVG cases go through fill="currentColor" with text-primary, because var() is not substituted in SVG presentation attributes. apexChartConfig.ts is deliberately left alone: its value is handed to ApexCharts as a plain string and written into SVG attributes, where neither var() nor a Tailwind class would resolve. Making that theme-aware needs a runtime lookup and belongs in its own change. Verified against ping.pub in dark mode: sidebar, active nav, nav text and svg fills are computed-style identical before and after.
…me_color
computedChainMenu writes --p inline on <body>. When the current chain defines a
theme_color that is the intended per-chain accent, but the else branch set a
hardcoded '237.65 100% 70%' - a duplicate of the `primary` already in
daisyui.themes. An inline style beats any stylesheet, so on every chain without
its own theme_color the configured primary never applied.
Found while writing the theming docs: changing `primary` in tailwind.config.js
re-themed base-100 but left buttons and the active nav on #666cff.
The fallback now clears the inline value so the theme's primary applies.
Chains that do set theme_color are unaffected and still override it.
cosmos (no theme_color) before #666cff regardless of config
after follows daisyui.themes
osmosis (has theme_color) rgb(130, 46, 214) before and after
One caveat: the fallback now resolves via daisyUI's hex -> HSL conversion, which
round-trips #666cff to rgb(102, 107, 255) rather than rgb(102, 108, 255). A
one-unit difference in the green channel - imperceptible, but not byte-identical.
There was no documentation for re-theming, which made the supported path hard to find - the daisyUI themes in tailwind.config.js. Adds a Theming section to installation.md with a worked example, a table of the tokens most people will reach for, and two caveats worth knowing: components that still hardcode a colour will not follow the theme, and the widget's injected stylesheet needs the postcss plugin to be outranked. The example in the docs was applied and verified end to end rather than written from memory; doing so is what surfaced the inline --p override fixed in the previous commit.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 80fc1f2e43
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The previous commit made the home logo's fill theme-driven (`currentColor` + `text-primary`) but left the pre-existing `dark:invert` in place. A CSS filter does not care where the colour came from, so in dark mode a deployer's configured primary is painted as its complement - with `primary: '#2dd4bf'` the logo renders red - which defeats the customisation this PR documents. Thanks @chatgpt-codex-connector for catching it. The adjacent `<h1>` is included even though this PR did not introduce it: the two are siblings in the same hero lockup and carry the same `text-primary dark:invert`, so removing the inversion from only the logo would leave the mark and the wordmark in complementary colours next to each other. Verified with the reviewer's example value: both now compute rgb(43, 212, 189) with `filter: none`, matching the configured #2dd4bf, where before the filter painted them rgb(212, 43, 66). Note this leaves ~30 other `text-primary dark:invert` pairs elsewhere in the codebase untouched. They predate this PR and have the same conflict with a customised theme, but they are outside the branding this change concerns.
2xburnt
force-pushed
the
pr/theme-customisation
branch
from
July 26, 2026 23:12
3667f32 to
5c96a00
Compare
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.
This pull request introduces a comprehensive theming system using daisyUI and Tailwind, ensuring consistent color usage across the application and improving theme customizability. It removes hardcoded color values in favor of theme tokens, enhances theme override reliability when using third-party widgets, and updates documentation to guide future theming changes.
Theming and Color System Improvements:
installation.mdexplaining how to customize colors using daisyUI themes intailwind.config.js, which tokens to use, and important caveats for consistent theming.src/components/dynamic/TextElement.vueso link colors use the theme'sprimarytoken instead of a hardcoded value.src/modules/[chain]/faucet/index.vue,src/modules/wallet/accounts.vue, andsrc/pages/index.vueto usecurrentColorand thetext-primaryclass, ensuring they follow the active theme color instead of hardcoded values. (src/modules/[chain]/faucet/index.vueL90-R90, [1] [2]src/stores/useBlockchain.tsto remove the inline--pvariable, allowing the theme's configuredprimarycolor to apply as intended.Theme Override Reliability:
postcss.config.jsthat increases the specificity of daisyUI theme rules, ensuring the app’s theme settings reliably override those injected by@ping-pub/widget.