I feel like utility classes had their moment and we can now start to pull back towards semantic CSS with the help of new features like CSS custom properties.<p>Instead of .f-green in your HTML you can do --f-green in your CSS.<p><header class="f-green"></header><p>would become<p>header {
color: var(--f-green);
}<p>or if you really hate CSS and must stay in HTML<p><header style="var(--f-green)"></header><p>Though the literal naming is a touch too specific anyway. Something like this is wonderful:<p>--f1-color: green;<p>header {
color: var(--f1-color);
}<p>then you don't have to do confusing things like<p>header .f-green {
color: red;
}<p>because you can do<p>header {
--f1-color: red;
}<p>So we can be less specific AND more modular... because you can have that f1 (font1) color be red in your header, and still do:<p>footer {
--f1-color: green;
}<p>We can make really flexible and extensible systems with modern vanilla CSS. No frameworks or preprocessors needed.
It's extremely important to create classes like `.f-green` in case the definition of green ever changes. That's what we call forward portability.<p>Also, if your company rebrands from green to red you can just `.f-green {color:#f00;}` - it's so efficient!
Yep, Tailwind didn't invent style tokens or composable classes! After learning Foundation, Tachyons, Material UI, Chakra...I was happy to see we finally settled on Bootstrap.<p>Oh, we didn't? Well, time to learn a new syntax. (Was it `<i>dark:md:hover:</i>text-slate-400` or `<i>hover:md:dark:</i>text-slate-400` again?) At least Tailwind arguably has more benefits than its predecessors.
I will always argue against this. Keep your layout in one file and your styling in another. I've done more CSS than most in heavy web production and I never once had a reason to think something like this would be faster or more efficient.
This is what I did before stumbling on BEM - <a href="https://en.bem.info/methodology/css/" rel="nofollow noreferrer">https://en.bem.info/methodology/css/</a>