Open maxsalven opened 9 months ago
What's the use case for this? The whole point of the library is to avoid setting up css variable, why not dynamically modify tw-colors produced variables instead of referencing your own?
In our SaaS app, the customer can choose their own brand color for their admin dashboard. We save this as a raw HSL value on our server for compatibility with Tailwind.
We then set the --brand
variable to their chosen color when rendering their admin dashboard. We have some logic that will adjust the color if there's not enough contrast, based on dark/light mode.
Many parts of our design are branded, e.g. buttons or focus rings. I'm simplifying things for a basic example:
"focus-ring": "var(--brand)",
"btn-brand-bkg": "var(--brand)",
"bgn-brand-bkg-hover: "var(--brand) / 0.7",
With this PR, these all just work now as long as your CSS (or inline styles) define --brand
.
Sure, we could put in dummy values:
"focus-ring": "#f0f",
"btn-brand-bkg": "#f0f",
"bgn-brand-bkg-hover: "#ff00ff70",
And then define these in a stylesheet:
--twc-focus-ring: var(--brand);
--twc-btn-brand-bkg: var(--brand);
--twc-btn-brand-bkg-hover: var(--brand);
But it's less ergonomic and you can't just update a field in the tw-colors
config, you have to go update a stylesheet as well and when there's actually multiple branded variables (think primary / secondary / dark / light etc) you need to make sure you're setting the correct values etc etc. Plus if you're using this alongside regular themes (blue/red/etc because branding is a feature for premium subscribers only) then you sometimes don't want to set --twc-focus-ring
to var(--brand)
. You also can't look in the tw-colors
config and immediately know if something is a dynamic customer-defined color or not.
Any progress for this? I have the same case of use.
Fixes https://github.com/L-Blondy/tw-colors/issues/39