I wonder if there are any initiatives to improve this, I was revisiting some old code that uses core components today and noticed that we redeclare classes for the base styles of an input (notice the border-zinc-300 and focus:border-zinc-400):
"mt-2 block w-full rounded-lg text-zinc-900 focus:ring-0 sm:text-sm sm:leading-6",
"phx-no-feedback:border-zinc-300 phx-no-feedback:focus:border-zinc-400",
@errors == [] && "border-zinc-300 focus:border-zinc-400",
@errors != [] && "border-rose-400 focus:border-rose-400"
PS.: If you follow this pattern, once you have to support a dark mode (or responsive variants) which is what I’m doing now, you start having lots and lots of duplicated classes.
I used daisyUI for a couple projects a while back, and it uses a Bootstrap-esque naming scheme for its colors (which are also fully customizable). Instead of hardcoding colors like bg-zinc-500, you just specify bg-secondary. I found it to work pretty well, and it makes it trivial to add additional themes, or modify existing ones (just change the color definitions in the tailwind.config.js file).
Component demos: Component Showcase - Quiz Game (You can change the theme by clicking the gear icon in the top-right corner.)
GitHub code:
Hi @arcanemachine, thanks for your contribution but this is unrelated to the problem I’m afraid 
… The point has more to do with how feedback state is being handled on inputs than what styling library to use, so using a different class name or library doesn’t really address the concerns posted by @AHBruns. Cheers!
The point is that you can use semantic class names instead of hardcoding color names. My input component can support a infinite variety of color themes without modifying the CSS of the component. The specific library is irrelevant. daisyUI happens to have the ability to do this. You don’t have to use the library to utilize the technique.
Awesome! That’s exactly what I was looking for, thanks for sharing @steffend.
