Looks good. I’d really like to use this. Mainly I like that the author used same approach as I do whereby with careful use of low specificity, a custom "btn" cl

Looks good. I’d really like to use this. Mainly I like that the author used same approach as I do whereby with careful use of low specificity, a custom "btn" class can be further customized just by adding TW classes (ie. not css specificity issues). My only gripe with this is that you should then use a clearly defined and separate naming convention for custom classes, for example SuitCSS is good: Not btn btn-large rounded-full But du-Btn du-Btn—-primary rounded-full ie. PascalCase component names, optional prefix (eg. du for daisy ui, because other apps also have their prefix see eg. Twitch and Algolia css) Bem conventions like double dash for modifier as opposed to a descendant https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md https://github.com/suitcss/suit/blob/master/doc/naming-conve... So yeah I would like to be able at a glance to know where a class is from. "btn" is not from tailwind, but where is it from? What if my app uses multiple components, from third party etc? It’s not clear. Other than that This is better than Bootstrap approach even with custom classes, because you take care of css specificity problem (assuming you can add a tw class anywhere and override the builtin custom classes)... this is the middle way that nobody uses for whatever reason, the one that makes sense, but requires a good basic understanding of css specificity as well as setup stringent css linter Also using a convention would let you use a good linter on the custom selectors https://github.com/postcss/postcss-bem-linter https://github.com/postcss/postcss-bem-linter