Tailwind is meant to encourage style re-use in two ways. The first is more obvious: there is a pre-set “theme” where colors and scales (like fonts) are centrally defined. The idea being if you want to change your branding colors, you can change them in one place by updating the config.
The second is more subtle: you are meant to use the component functionality of your framework of choice. For some this could be React - for us it’s Phoenix components (heex). Ideally you factor out as much structure as possible into re-usable components.
There are always going to be one-off components somewhere, and those have to be styled individually. There is no way around that. If you place a one-off component into your style-guide and then only use it once, you have achieved no meaningful standardization.
Like I said, I think Tailwind does a good job solving big problems with CSS. Obviously it does something right given so many swear by it. I will say, though, that having used both I am much happier with my own solution.
I did not, so I’m not sure what you’re referring to.
The default CSS file is generated by Tailwind. So it is not expected to be beautifully readable CSS. Our goal here was to provide people using --no-tailwind with a styled application. Previously, they ended up with completely unstyled pages. I know that not everyone will be happy with that, but we don’t have the capacity to maintain a completely separate set of hand-rolled CSS for --no-tailwind, especially since it’s very likely that people are going to rip those out and replace them with something else anyway.
1 Like
I did not, so I’m not sure what you’re referring to.
There see to be two tickets linked here and the one I found was locked. I’ll have to dig in my browser history.
Previously, they ended up with completely unstyled pages. I know that not everyone will be happy with that, but we don’t have the capacity to maintain a completely separate set of hand-rolled CSS for --no-tailwind ,
I’ll try this out once 1.18 lands and see how it goes. I’m hopeful that daisy will be better despite being a tailwind plugin. At present there’s a lot of classes still in core_components. An excessive number on the labels, including font sizes which are complicating layout. I started a PR to clean some of that up but then I noticed things are already in flux so I’ll take a beat and see.
Like I said, I think Tailwind does a good job solving big problems with CSS. Obviously it does something right given so many swear by it. I will say, though, that having used both I am much happier with my own solution.
I want to say that avoiding libraries that are polarizing is a good thing to do in frameworks, but that is a difficult bar to reach.
As for maintaining an alternative CSS tree, I hear you. Especially if people start contributing components (I had one but you guys beat me to it). It’ll get out of hand. The best other suggestion I can think of is one of the minimalist CSS base files, making it a Vendor A/Vendor B choice instead of third party vs in house.
Ah, you’re referring to the original proposal by José which indeed was locked as the discussion ended up just being either people saying they like daisyUI (and the change) or they don’t - even after the decision was already made.
The current version of the CoreComponents can be found here: phoenix/installer/templates/phx_web/components/core_components.ex at main · phoenixframework/phoenix · GitHub and we’re not planning on doing any more changes to them at the moment. If you see opportunities to simplify them even further, please send a PR and we’ll evaluate it for the next RC.
