I really don't see the benefit. Sure, you don't write "CSS", but you write a lot of classes that look like CSS. If you write class="bg-white no-underline" you could easily write style="background: white; text-decoration: none;" and every frontend guy will understand it. I don't get the point.
If this article didn't make it click for you, that's understandable. It took me a long time of hearing about this & thinking it was stupid before it made sense. When that happens to me, it's usually a sign of something good.
But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray?
these inconsistencies compound, especially across teams.
Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.
I admit, after the middle of that article anything would look good.
It's a good realisation that there is no real separation of semantics and styling between HTML and CSS. XSL would have been one solution, but it was just too XML-ly. Personally I found it a joy; I could design my pages with pure semantics alongside a turing-complete stylesheet.
However now we have web components - your HTML and CSS are tightly coupled, but scoped. And the semantic / styling separation is provided by the shadow DOM. So no need to create inner platforms like Tailwind.
