Customize the colors #176
-
|
Hi, FluxUI aims to solve two key problems:
By providing a “complete package” that addresses both issues, you need to be fully aligned with the two proposed solutions. In 2024, we should embrace modern approaches and avoid overwriting CSS styles with other styles, as was common during the era of WordPress themes. Instead, we should have a system that generates element properties like border radius and colors through the abstraction of CSS variables. I believe FluxUI handles the first problem very well, and any need to tweak functionality or components can be logically addressed through publishing the components. However, for changes such as adjusting border radius, lg heading size, or primary colors, we should rely on a dedicated stylesheet with CSS variables. The documentation mentions the following : [data-flux-button] {
@apply bg-zinc-800 dark:bg-zinc-400 hover:bg-zinc-700 dark:hover:bg-zinc-300;
}However, a better approach could be something like this in the tailwind.config.js : module.exports = {
theme: {
extend: {
colors: {
'flux-primary': {
300: '#A3BFFA',
400: '#7F9CF5',
700: '#2C5282',
800: '#2A4365',
},
},
},
},
};At least for the action/primary colors. Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 39 replies
-
|
Hmmm. I agree, but I'm not sure how easy it would be to implement. @apply is fine for a couple hacks you just can't fix for some reason, but think about styling the "switch ON" color, button backgrounds+borders+text+focus, badge colors, now add dark/light mode, and now do it in all components. Suddenly it's not so fun and you're publishing everything just to change blue to teal, zinc to gray, or creating a cumberson set of @apply rules you have to manage and maintain. Flux seems to be using nearly all the default Tailwindcss colors (see Badge variants). It's also using the default Tailwind colors Zinc for both text and PrimaryButton colors. So you can't simply re-map Zinc to Primary. The only way I can think of solving this is for Flux to create it's own brand colors, then allow you to override those (like WireUI does below) const colors = require('tailwindcss/colors')
module.exports = {
...
theme: {
extend: {
colors: {
...
primary: colors.indigo,
secondary: colors.gray,
positive: colors.emerald,
negative: colors.red,
warning: colors.amber,
info: colors.blue
},
},
},
...
}But - this would require everything in flux to be written with those brand colors. EG: default: bg-base-500; /* instead of Zinc so it can be overwritten */
primary: bg-flux-500;
secondary: bg-pulse-500;
positive: bg-boost-500;
negative: bg-glitch-500;
warning: bg-flare-500;
info: bg-signal-500;Not ideal but would be easy to customize once implemented. Maybe I'm missing something and there's a simpler way. |
Beta Was this translation helpful? Give feedback.
-
|
FluxUI aims to solve two key problems: By providing a “complete package” that addresses both issues, you need to be fully aligned with the two proposed solutions. In 2024, we should embrace modern approaches and avoid overwriting CSS styles with other styles, as was common during the era of WordPress themes. Instead, we should have a system that generates element properties like border radius and colors through the abstraction of CSS variables. I believe FluxUI handles the first problem very well, and any need to tweak functionality or components can be logically addressed through publishing the components. However, for changes such as adjusting border radius, lg heading size, or primary colors, we should rely on a dedicated stylesheet with CSS variables. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed - overriding styles with CSS/@apply, or needing to publish all your components just to get colors right, are not long-term solutions. Here are my custom brand colors - imagine trying to get Flux to play nicely in all situations? 
Even if I published everything, there is a lot of work required to find+replace, test, tinker, etc. Not to mention now I have to manually update every component in the package until the end of time, just because I wanted my own colors. As an example, right now Flux uses The only long-term and maintainable solution is to create a set of branded Flux colors that are configurable in the Tailwind config. That way I can simply remap I'd be happy to work on a PR, but it would need conceptual approval first as it touches everything. The change itself shouldn't cause any issues for end-users:
I hope this get's considered 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
Any news on this ? Before buying flux, I was benchmarking other component library, and I think daisyUI is handling the subject pretty well : https://daisyui.com/docs/themes/#-5 It would be so much simple to use flux in any existing project, as for now, we have to publish every single component to be able to match our branding But even as it is, flux remain an amazing product :) The amount of work put into flux is astonishing |
Beta Was this translation helpful? Give feedback.
-
|
That's indeed a great way to set the variables :) Hopefully Caleb and Hugo will use this approach. |
Beta Was this translation helpful? Give feedback.
-
|
Publishing the stubs just to change the colours is a no-go, as is keeping everything monochrome when we actually have a brand and colours we're quite happy with. I think this feature should be given a bit more consideration that it currently is. |
Beta Was this translation helpful? Give feedback.
-
|
This was my solution. I wont be able to use zinc anymore, but that's fine by me. If we also get a |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. Sometimes I need gray text, sometimes I need blue, depends which part of the UI I'm in. I just realized, in theory, you could remap Zinc to CSS vars like I haven't tested this idea in Flux, but I made and use this instant tailwindcss color theme switching code and it works like magic 🪄 |
Beta Was this translation helpful? Give feedback.
-
|
What are all the elements that you would want to be a "primary" color? I can think of two off the top of my head:
Am I missing any? |
Beta Was this translation helpful? Give feedback.
-
|
For me, it’s mostly the Zinc that doesn’t vibe with my apps. It’s too ”gray” to fit in. But yeah, apart from that, the elements mentioned above 🙏🏻 |
Beta Was this translation helpful? Give feedback.
-
|
Good calls - what. What would you want to be done for dark mode? Do you envision wanting colors in dark mode too? or just the primary white(ish) being fine? |
Beta Was this translation helpful? Give feedback.
-
|
Well, if it's possible, then what badges do would be best in my mind. Basically replace // from Badge source
text-lime-800
[&_button]:!text-lime-800
dark:text-lime-200
[&_button]:dark:!text-lime-200
bg-lime-400/25
dark:bg-lime-400/40
[&:is(button)]:hover:bg-lime-400/35
[&:is(button)]:hover:dark:bg-lime-400/50That way the "shades" should still work and feel cohesive with what you've already built and would still suport light/dark mode. I just don't know how this works technically with the tailwind bundler and blade as I've never tried, but I assume it's possible? Seems like a win/win solution if it is! |
Beta Was this translation helpful? Give feedback.
-
|
That's tricky because as you can see from the badge source, everywhere we would have that "color" property, we would need a GIANT match statement for every single color combo. And those would have to be fine-tuned on a per-component basis. |
Beta Was this translation helpful? Give feedback.
-
|
I thought that might be tricky. If that's the case then a custom It seems WireUI allows you to pass an existing color scheme to primary/secondary - I wonder how they handle it, I will look tomorrow. DaisyUI handles it differently again. |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick shot of what I've been hacking on: I'm toying with the following set up: You want to change from "zinc" to another "gray" color globally? You should modify the meaning of "zinc" in your tailwind config: theme: {
extend: {
colors: {
zinc: { // These are all "gray" colors...
50: "#f9fafb",
100: "#f3f4f6",
200: "#e5e7eb",
300: "#d1d5db",
400: "#9ca3af",
500: "#6b7280",
600: "#4b5563",
700: "#374151",
800: "#1f2937",
900: "#111827",
950: "#030712",
}
},
},
},You want to change the primary color for buttons and the like? You should define the following CSS variables globally: <style>
*, ::before, ::after {
--flux-primary: #2463EB;
--flux-primary-dark: #1D4ED8;
}
</style>To make this work, Flux would now internally use Tailwind classes like the following:
|
Beta Was this translation helpful? Give feedback.
-
|
In my case, I actually prefer the zinc for a project I'm working on. After all of the design work that Hugo and @calebporzio put into the Flux UI and colours (yes, Canadian spelling ;), zinc being Hugo's choice & recommendation, I think it is better that we find a way to customize (per this discussion) on a per dev, project basis and leave the defaults as is. |
Beta Was this translation helpful? Give feedback.
-
|
@calebporzio your quick fix works in some ways, but it is a patch and not a solution. The user should be able to change the primary color that is set for primary color. Not zinc color that is the primary color. You should abstract the contextual color with the actual TailwindCSS colors so we can bridge the primary to whatever we want, not overwrite the zinc TailwindCSS color with something else. |
Beta Was this translation helpful? Give feedback.
-
|
what do you think about this approach tailwind.config.js: result 
|
Beta Was this translation helpful? Give feedback.
-
|
It seems that adding the secondary variant is causing an additional issue when trying to apply either the filled or outline styles with it! |
Beta Was this translation helpful? Give feedback.
-
|
Hmm.... I thought about this a lot and I think I like @calebporzio's MVP the most. I can't test how the CSS vars work, but right now I like that Flux has a stylized design which is mostly based off Zinc. This is good as it's consistent and flows through everything. It may not be ideal for those who want a lot of control, as remapping zinc to another color changes things like borders, shadows, etc, but I kinda like it. Forces an aesthetic. I have some tailwind/scss/CSSvar shenanigans in my project where I can do this <x-flux-bundle class="theme-gray"/>
<x-flux-bundle class="theme-green" />
<x-flux-bundle class="theme-blue" />
<x-flux-bundle class="theme-red" />
<x-flux-bundle class="theme-teal" />With this magical result
It also works for any individual flux component by adding <flux:switch data-checked class="theme-purple" />
I built it as I needed to be able to change tailwind colors on the fly using Javascript without every I'm not sure on a 'best' solution...
For how I would use Flux I actually don't think I need anything else as I can use any color combo I want, but being able to specify a primary seems useful for others, I just need to play with it to see how it works. |
Beta Was this translation helpful? Give feedback.
-
|
As a temporary solution, here's what I do on my main buttons. .btn-primary {
@apply bg-blue-700 hover:!bg-blue-800 shadow-none !text-white dark:!bg-blue-700
dark:hover:!bg-blue-800 dark:shadow-none dark:border-none
}<flux:button class=“btn-primary” icon=“plus”>Add</flux:button>
Otherwise, I propose for a minimum choice at the beginning, if a color is specified be able to choose our tailwind color a bit like this : <flux:button color="teal" icon=“plus”>Add</flux:button>@unless(isset($color))
@php $color = 'zinc'; @endphp
@endunless
<button class="bg-{{ $color }}-800 [...]">It's not the best, but I can't imagine anything better for “easy” customization. |
Beta Was this translation helpful? Give feedback.
-
|
@apply is a way to handle it for sure. Not my favourite but it works. I'd love to be able to pass color="teal", but run |
Beta Was this translation helpful? Give feedback.
-
|
Here's what I have been doing as a temporary workaround in my published version of Button, for example: In the button source, I added a $attributes = $attributes->merge([
"data-flux-variant-$variant" => "data-flux-variant-$variant"
]);Then, in the CSS (I have bg-primary defined in my Tailwind config): [data-flux-variant-primary] {
@apply bg-primary;
} |
Beta Was this translation helpful? Give feedback.
-
|
Great, but it requires publishing assets and that's what everyone is trying to avoid for basic primary/secondary themeing. |
Beta Was this translation helpful? Give feedback.
-
|
It only requires publishing assets until there is an official way to do this (hence, temporary workaround). I also had sent this idea into support when Flux was first released as a potential way to do themes. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, has there been any official movement on this? This is the most requested item, and nothing has happened since release. |
Beta Was this translation helpful? Give feedback.
-
|
Just getting around to using Flux on a new project. The inability the theme Flux is a deal breaker for me. |
Beta Was this translation helpful? Give feedback.
-
|
Any update from @calebporzio and @joshhanley on the potential timeline/roadmap of this majorly requested feature would be amazing and clarifying! Thanks :) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it's hard to handle colors. The zinc is too dark for what I want in my projects. I think the "primary" should never be a hardcoded color like zinc or blue. It should be what's set in tailwind config as primary. |
Beta Was this translation helpful? Give feedback.
-
|
@jfvoliveira completely agree. Flux is awesome and they're trying to accommodate everyone's unique needs. My app looks much better already. For me having things like searchable select or radio groups in one line is just an incredible asset. Zinc is just not my color for action buttons. Caleb has a temporary solution to what I'm looking for which will do for now. |
Beta Was this translation helpful? Give feedback.
-
|
I'm guessing Caleb will eventually PR his demo Because for me that actually was a fine solution. I will look at making my own theme-solution into some add-on next year, because it works like magic. I just have a big deadline and can't work on open source right now. But maybe it'll be solved by then ;) |
Beta Was this translation helpful? Give feedback.
-
|
Heads up: this is my primary focus. I'm exploring all sorts of solutions right now and will come up with something soon to at least style buttons and such. |
Beta Was this translation helpful? Give feedback.
-
|
Your latest podcast on this topic was pure gold 😂. Agreed with your synopsis, simple var() / accent is the way to go for v1. |
Beta Was this translation helpful? Give feedback.
-
|
You mentioend in the previous episode "why can't tailwind generate a palette based off one RGB value?". This is entirely possible. In my app, I have a command that extracts the 'dominant color' from category images to a hex code, I use this to theme the page based on that image.
I hacked this for my own use: https://github.com/bobthered/tailwindcss-palette-generator (haven't had time to PR my changes). But the end result is similar to how https://uicolors.app works. Not sure if it's useful, since what you described about Shadcn/Radix are very different takes, but it is possible to compute tailwind style palettes on the fly. |
Beta Was this translation helpful? Give feedback.
-
|
Good to hear it! And yeah, I was checking out uicolors.app yesterday - insanely cool |
Beta Was this translation helpful? Give feedback.
-
|
No worries! I just finished your 2nd last podcast and now understand where your thinking is for Flux v2. So now I have a few more opinions I think are worth sharing as I've been thinking about this conundrum on and off since october. I don't have a perfect solution, but I can 'feel' one, if you know what I mean. My first comment mentioned
This goes along with your thinking around potentially using Radix vs TailwindI haven't used Radix but a quick read of the docs has me confused. Either way, I can't imagine mixing two different color systems using different scans of 1-12 and 50-950 will be super fun long term. Auto Light/Dark modeWouldn't this be damn cool? I wanted this myself, and did a few AI experiments in a car trip. This one converts using HSL, this one sets a color-adjusted dark/light mode. Both seem 'feasible', but probably too hard in practice. And I bet Hugo will have strong opinions when he seems the auto-conversions. "Perfect" design is sadly never programmatic in my experience, too many nuances. How Tailwind Handles ColorsYou should talk to Adam, but from my understanding Tailwind stores all colors as hard-coded OKLCH values, and references them as HEX. It compiles them into a 'compound(?)' css var using RGB and uses an opacity with a fallback, so background-color: rgb(92 146 255 / var(--tw-bg-opacity, 1));Sadly I don't believe you can reference tailwind CSS colors vars() directly because of this. You can only do that with your own CSS vars. CSS, cascade, accent and colorsSo what are we trying to achieve? I think it boils down too..
This doesn't use tailwind, but it's a decent example of how I imagine a solution could work (click the dice to re-roll color vars). You essentially pass all your own color vars and you end up with something that is branded. So let's imagine we're using Tailwind v4 because the syntax is nicer (but it's the same in v3) @fluxStyles would setup the accent colors as css vars Flux components would use them And then in app.css I could override them. There are other solutions mentioned above, auto dark mode, maybe Radix style declarations, but these probably get too complicated. I cannot think of a simpler solution. Maybe if all colors were computed at run time you could do this differently. But even then you'd end up in a position where you have to either compile all the possible colors you want people to be able to use ahead of time (because tailwind wont), or, compute them on the fly using a "HEX" code like I do in my app The drawback here is a hex code needs to be computed to use the tailwind 50-950 spectrum, so if you've hard coded bg-color-500 on a class (which you have too), and they pass a color="X" value that is closer to 200 or 700 (too dark or too light), then you need to adjust that to figure out the 500 value,similar to how uicolors and my own app do it. You'd be 'helping' the person while also 'annoying' them since the color they pass might not be the color they get, if you get me. It's a bastard of a problem, so many tunnels with no obvious way out. And most frustratingly, no perfect solution with compromises all the way down. But I hope this is of some value. Good luck! |
Beta Was this translation helpful? Give feedback.
-
|
That's a great answer ! |
Beta Was this translation helpful? Give feedback.
-
|
What about using variables in the Tailwind config so brand colors can be configured in PHP, similar to Filament?
You could offer preset constants people can use, or they can use custom values. This approach means more possibilities for dynamic theming. For example a multitenant app where tenants can choose their own color. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. I used Filaments Color stuff recently but didn't dig into the source. It's not too different to a few other proposed solutions, but it's nice seeing a PHP-first implementation. It would probably make it easier to publish non-breaking changes, and avoid conflicting with tailwind configs. I dug a bit and this is the issue with how Filament does it: <button style="--c-400:var(--primary-400);--c-500:var(--primary-500);--c-600:var(--primary-600);" class=""></button>This works I guess, but it doesn't look like fun to implement and maintain. But.... there's something here. I can't put my finger on it, but I use custom var() tailwind themes in my app and it works like magic, and I'm positive the answer lies somewhere in there. I just can't put my finger on it yet. Working on it. |
Beta Was this translation helpful? Give feedback.
-
|
YES - I figured it out! This has been bugging me for months. It might not be what Caleb goes with, but it's simple, unique, very poweful, and now its finally out of my head. Flux at it's core is 99% zinc. Do a CTRL+F here and you'll see (769 matches!): And it works well. So... what if we lean into this and re-mapped zinc to be a dynamic var-based tailwind theme? The steps below are basically what I do in my own app, but adapted to Flux. This is an excellent article I found earlier breaking down the concept in more detail: Everyone interested please follow along step by step:
colors: {
flux: {
50: 'rgb(var(--flux-50, 250 250 250) / <alpha-value>)',
100: 'rgb(var(--flux-100, 244 244 245) / <alpha-value>)',
200: 'rgb(var(--flux-200, 228 228 231) / <alpha-value>)',
300: 'rgb(var(--flux-300, 212 212 216) / <alpha-value>)',
400: 'rgb(var(--flux-400, 161 161 170) / <alpha-value>)',
500: 'rgb(var(--flux-500, 113 113 122) / <alpha-value>)',
600: 'rgb(var(--flux-600, 82 82 91) / <alpha-value>)',
700: 'rgb(var(--flux-700, 63 63 70) / <alpha-value>)',
800: 'rgb(var(--flux-800, 39 39 42) / <alpha-value>)',
900: 'rgb(var(--flux-900, 24 24 27) / <alpha-value>)',
950: 'rgb(var(--flux-950, 9 9 11) / <alpha-value>)',
},
}
// here
@props([
'color' => null,
])
// and here
$classes = Flux::classes()
->add($color ? "flux-{$color}" : '')
<div>
<style>
.flux-purple {
--flux-50: 241 242 252;
--flux-100: 229 230 250;
--flux-200: 209 209 244;
--flux-300: 181 180 237;
--flux-400: 158 150 227;
--flux-500: 140 124 216;
--flux-600: 114 86 197;
--flux-700: 107 82 176;
--flux-800: 88 68 143;
--flux-900: 73 61 114;
--flux-950: 43 35 67;
}
</style>
<div class="space-x-2 p-4">
<flux:button>Default</flux:button>
<flux:button variant="primary">Primary</flux:button>
<flux:button variant="filled">Filled</flux:button>
<flux:button variant="danger">Danger</flux:button>
<flux:button variant="ghost">Ghost</flux:button>
<flux:button variant="subtle">Subtle</flux:button>
</div>
<div class="space-x-2 p-4">
<flux:button color="purple">Default</flux:button>
<flux:button variant="primary" color="purple">Primary</flux:button>
<flux:button variant="filled" color="purple">Filled</flux:button>
<flux:button variant="danger" color="purple">Danger</flux:button>
<flux:button variant="ghost" color="purple">Ghost</flux:button>
<flux:button variant="subtle" color="purple">Subtle</flux:button>
</div>
</div>
Dark mode:
Now, this is not a panacea, but it's pretty close....
So... the flux components that would support this would need to be somewhat refactored. Danger can be removed, and instead you can just pass you color="red" or color="danger". But you can also leave it so it's not a breaking change. ->add(match ($variant) { // Background color...
'primary' => 'bg-flux-800 hover:bg-flux-900 dark:bg-white dark:hover:bg-flux-100',
'filled' => 'bg-flux-800/5 hover:bg-flux-800/10 dark:bg-white/10 dark:hover:bg-white/20',
'outline' => 'bg-white hover:bg-flux-50 dark:bg-flux-700 dark:hover:bg-flux-600/75',
'danger' => 'bg-red-500 hover:bg-red-600 dark:bg-red-600 dark:hover:bg-red-500',
'ghost' => 'bg-transparent hover:bg-flux-800/5 dark:hover:bg-white/15',
'subtle' => 'bg-transparent hover:bg-flux-800/5 dark:hover:bg-white/15',
})So it's mostly upside as I see it! Update: Another thought comes to mind. The color prop could accept a #hex value. Since we're using PHP, this means you could compute colors on the fly (I already do this in my app). All you'd need is to detect the hash in the prop and run a function to generate the |
Beta Was this translation helpful? Give feedback.
-
|
Here's a quick Claude AI hack job that works with the code above - just to demo what a 'live' flux theme preivew could look like. It auto-adjusts to try prevent too-dark/too-light. Just add it to your blade to play with it. <script src="https://cdnjs.cloudflare.com/ajax/libs/alpinejs/3.13.5/cdn.min.js" defer></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/chroma-js/2.4.2/chroma.min.js"></script>
<div x-data="{
baseColor: '#7E22CE',
updateFluxColors() {
const inputColor = chroma(this.baseColor);
const levels = {
50: 98, 100: 96, 200: 93, 300: 88, 400: 76,
500: 65, 600: 55, 700: 45, 800: 32, 900: 25, 950: 18
};
Object.entries(levels).forEach(([level, targetL]) => {
const adjusted = inputColor.set('lab.l', targetL);
const rgb = adjusted.rgb();
document.documentElement.style.setProperty(
`--flux-${level}`,
`${Math.round(rgb[0])} ${Math.round(rgb[1])} ${Math.round(rgb[2])}`
);
});
}
}"
x-init="updateFluxColors">
<input type="color" x-model="baseColor" @input="updateFluxColors()" class="h-10 w-20">
</div> |
Beta Was this translation helpful? Give feedback.
-
|
Nice work on this @mauricekindermann |
Beta Was this translation helpful? Give feedback.
-
|
Ok, Flux has colors now. Thanks everyone for upvoting this and helping me prioritize! |
Beta Was this translation helpful? Give feedback.
-
|
Wow, wild! The frontend theme builder and the tablet/mobile versions are stunning. 💎 Very cool solution for the themes to invert the text/bg colors for Orange vs Amber etc. I guess you have hard coded a theme for each of the tailwind color gamuts. Using color mix on hover is also super cool. Bravo. 🥇 |
Beta Was this translation helpful? Give feedback.
Ok, Flux has colors now. Thanks everyone for upvoting this and helping me prioritize!
https://fluxui.dev/themes