No? Neither did I. I stopped thinking about CSS entirely almost a decade ago. Thanks Tailwind.
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?
That handles consistent sizing, spacing, text, colors, dark mode, and anything else your design system needs. It all compiles down to css in the end, so no runtime overhead and gives you the superior tailwind dx during development.
It's a utility to generate deduped/treeshacken css classes - according to a config file the parent mentioned
It's not some grand framework or something.
It's literally doing exactly what the grand parent said. Define root css variables, and generate the applicable/used css classes that were used in the code
I don’t understand where the disagreement is. I was only pointing out a lot of the “magic” from Tailwind’s abstraction isn’t as magical as the GP you referred to implies.
I simply answered his question - tailwind is indeed just plain old CSS with a more ergonomic DX.
// Styling a simple button <button class="btn"> daisyUI Button </button>
So, we are back to regular CSS?
You use Tailwind in the same way you use BEM: becuase it makes it easier for frontend developers to write correct CSS.
And as you say, it’s for semantics so I wouldn’t use .button anyway as it doesn’t carry the right specificity for styling.
And just a shared color definition file.
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)
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.
Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?
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.