Earlier quoted context omitted.
I'm talking about the design aesthetics included in Tailwind as default. Keep the values and the names if you want. Like this, for example: "blue-500" becomes --blue-500. That's it. This is a far cry from using Tailwind as a whole while keeping the good-looking aesthetics.
Sure now do the same for: whitespace (margins and padding), border radiuses, shadows, opacities, font sizes, font weights, and continue playing whack-a-mole as you run into new cases. Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set of classes that took you zero hours of initial setup and will cost you zero hours of maintenance outside of your…
And the IDE will help you autocomplete it all. The same is true for all the other properties you enumerated. If it's a Tailwind design token, it can be a pure CSS design token. No "whack-a-mole" needed here.
Still, you're right about having documentation. And there has been a loooot of these kinds of doc (BEM, SMACSS, ITCSS, etc.) in the last 15 years. Nonetheless, a more modern-oriented one is indeed needed. And that's why I'm working on something like this.
As for the "15 seconds", I mean, really? If so, I beg to disagree. There is a lot to take in. And that is why numerous colleagues still have to open the Tailwind docs to know how to write a class that's not 1:1 CSS.
And lucky you if you haven't had any update and dependency issues in the medium to long term. But I know we had.
> Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set "of CSS features".
The sentence above is every bit as true as yours. Add a beautiful design language and you are in business.