We've gone full circle - CSS components to inline CSS-in-HTML back to CSS components.
But I actually think I will use this. A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS. Hence Tailwind's "CSS-in-HTML" mini classes. But that doesn't fill the core purpose of CSS, bigger general-purpose classes to avoid repetition. Combine the two (general classes + mini classes for slight case-by-case fixes) and you get the best CSS experience I've seen so far (at least I think, I haven't tried it yet).
> A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS.
10000% agree with this. I have found that copy/paste until you need to go back and change the same value a few times is worth its weight in salt with CSS. Never has "a poor abstraction is worse than duplicate code" been truer than in CSS.
What I found in my FE days ways that it wasn't until the project shipped and we were iterating on v2 did the actual reusable classes appear.
Interesting. I write CSS with absolutely no overrides. I compose at the JSX component level, so there's one Button component used everywhere, not a btn class that gets applied to random <button> components. I usually need to reuse more than just a style, so why not encapsulate it at the component level? If I _do_ want to compose individual styles, I use Sass mixins.
And I find that looking at a single media query over semantic classes to be far easier to understand than utility classes scattered over multiple elements. Looking at tailwind responsive classes hurts my brain.
idk, I've been using tailwind for the past 4 months on a large and complex project, and I haven't had to override a single class. There were a few instances in which I needed to write custom css to handle certain scenarios, but that is roughly 100-200 lines of css.
I also never had to do it when I was using Emotion, and I used that for 2 years.
I also haven’t done much CSS since bootstrap 2.x days. I wonder if there is some tooling you would run in your CI to propose CSS changes - not failing like most linters but just nudge the devs a little to improve on low hanging fruits.
Really? You can layer classes or even use IDs for something super specific. The only time I use overrides/in lines are when I’m testing/troubleshooting.
I think the thing with Tailwind that people are missing is the opinion that CSS's bigger general purpose classes to avoid repetition have failed. However, most of us are using some kind of HTML templating system. What matters is that the design work only happens once in the code, repetition in the finished product is just fine. So moving the job of avoiding repetition out of CSS and into your HTML templating system is the right way to go.
HTML templating (specifically FreeMarker macros) is what i’m doing now.
There are still some cases where classes are useful, like JS or when I have very different components with some shared style. But these are mostly edge cases. FreeMarker has some other problems though.
Using a convention for custom classes helps distinguish from tw classes and other libraries, and allows stringent linting of css selectors to make sure the specificity issue is covered (without using !important on all tw and custom utilities which imho is a bad solution).
But I actually think I will use this. A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS. Hence Tailwind's "CSS-in-HTML" mini classes. But that doesn't fill the core purpose of CSS, bigger general-purpose classes to avoid repetition. Combine the two (general classes + mini classes for slight case-by-case fixes) and you get the best CSS experience I've seen so far (at least I think, I haven't tried it yet).