This approach is extremely seductive because on the surface it sounds so "pure" and "clean" but the reality is that on large projects it leads to some of the most horrific, hard to maintain CSS you'll ever see, no matter how hard you try to keep things in good shape. CSS is just inherently more difficult to maintain than HTML, and choosing a workflow that encourages editing CSS instead of HTML just makes things harder and harder over time.
Choosing an approach where CSS is treated like a third-party dependency that is _consumed_ by your HTML ends up being much more practical, maintainable, and scalable because editing and maintaining HTML is _easy_ — every time you change a class on an HTML element your changes are local and predictable.
Always thought this article by Nicolas Gallagher did the best job arguing this point:
CSS Zen Garden is from a time when people still used tables and font tags to design their pages, and as such it was a pretty powerfull way to convince people there are better and more efficient ways to do things.
I think the important part here is "efficient". It is more efficient to go to a style sheet and change a color instead of 1000 font tags, but in other ways it's just more efficient and easier to adjust your template-generated html and be done with it. Or write it from scratch.
The thing that I think doesn't work very well with this way is reusability. Rarely do you have this one thing you've made, and that you can use in the completely same way in another place. So you end up adjusting the style through CSS for a specific case, which eventually results in having rules like .foo > .bar:not(.baz) :first-child and making a change there results in playing whack-a-mole: you change something, break it in another place, fix it there, now it breaks in the third place etc. This is even worse if you have multiple people doing quick fixes.
There are other reasons too, but in general all of that is fine if you want to do a one-off thing to see if it could be done. Especially if you're a designer writing the code yourself. But getting a finished design from somebody who doesn't care about code is different because you cannot really predict what people will think of -- and I've actually never seen anybody do a redesign like this.
But can you do what CSS Zen Garden does only by changing HTML? If you can't, it means you failed at separating concerns.
Additionally, applications that you need to customize/theme usually makes it hard for us to edit the HTML. The only option is to edit the CSS. In this case, you whole argument breaks down.
p.s.:
In your case, I believe Tailwind should be pushing more for the use of @apply, instead of making those god-awful markups :(
> But can you do what CSS Zen Garden does only by changing HTML?
Yes of course you can, if you can change the HTML you can build an entirely different website, and you don't have to change the CSS at all because with something like Tailwind it's a "universal stylesheet".
Not true at all. You can build two sites that look completely different without changing the CSS at all if the API of the CSS framework is low level enough, like Tailwind, Tachyons, etc.
Agreed. I was a big proponent of the csszengarden way of developing sites. Then during the development of my latest site [0], I decided to use bootstrap for styling. And now I am really liking it. Makes things much easier, at least for me.
[0] https://embit.ca
Choosing an approach where CSS is treated like a third-party dependency that is _consumed_ by your HTML ends up being much more practical, maintainable, and scalable because editing and maintaining HTML is _easy_ — every time you change a class on an HTML element your changes are local and predictable.
Always thought this article by Nicolas Gallagher did the best job arguing this point:
http://nicolasgallagher.com/about-html-semantics-front-end-a...