I see you have a .button, cool! So did you load the entire context of your project into your mind, and calculate every possible iteration of kind, size, color etc this button may have? And once you did that, did you come up with a semantically correct naming scheme that is clear and will not succumb to the inevitable .button_checkout_special_page_cta_widget a particular page will end up requiring?

No? Neither did I. I stopped thinking about CSS entirely almost a decade ago. Thanks Tailwind.

It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a <button>, so no, I wouldn’t have a .button class, it’s superfluous.

What I would have is:

- a global palette specified via CSS variables

- overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level

- CSS module files so I specifically don’t need to care for the context of my entire project, just the classes for my current component

Of course, you stopped thinking about CSS a decade ago so you don’t know about any of these improvements. Which is fine but it strikes me as a little strange to be so boastful of ignorance.

As someone who has barely touched Tailwind I’m genuinely curious: if you wanted, say, a consistent border color for use across your project how would you? Are you defining a class name in JS for use with $framework_name? And do you really style each component separately for dark mode? Repeating the same modifiers over and over?

I feel like scoped css and component libraries fixed this issue. I don’t have a .button, I just have a <Button> that has all its css self contained.

And just a shared color definition file.

You still have to remember what sizes or whatever to use for what to make it consistent, it’s just they get packed into the “class” attribute. It’s not uncommon to see very long class attribute lines with tailwind with all kinds of p-this and mx-that or whatever. I’ve also seen quite a lot of p-[whatever] tags, at which point all the consistency goes out the window.

So you end up wrapping the components (if you’re using react or something similar) so that you can centralise the styles and use a set of consistent components instead. And at that point it really doesn’t matter if you use tailwind, custom classes, per component css modules, style attributes, css-in-js, or what have you. At this point I prefer to drop the extra dependency and use per-component css files with css module imports. (Or when I do less custom styled UI’s, I prefer to use Mantine and use its attributes for layout and styling)

Yes. Bootstrap and all other CSS frameworks before Tailwind did it, too.

It's a matter of preference, but many times it's easier to have single classes so that all your buttons are consistent.

People should just use the tool they're more productive with.

I know what you mean. But somehow that doesn't bother me. In fact it forces me to think about consistency of the design and often makes me think of a more general schema and simplifications in styling, or getting rid of something too specific/special.

Don’t you need to keep more context in your mind if you use Tailwaind to make .button_checkout_special_page_cta_widget while staying somewhat consistent?

Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?

Yes.

you just add `checkout` class or `big` class to your button. or use `.checkout-page .button` to modify look/size of your whatever button on the checkout page if it's style is truly unique and not used anywhere else.

What? I don't even know what you're talking about, and I've written mountains of vanilla CSS code in big projects.