100% this.
The moment I started to see HTML and CSS as a holistic system of layout construction, rather than as simply two separate but complimentary technologies, my productivity in both skyrocketed.
'Bugs' in my CSS became infinitely easier to not only find, but also solve. And the benefits of tools that both unified and abstracted layout construction, like Tailwind, became immediately obvious.
Shameless plug: I talk more about a lot of these mindset shifts and how they've helped me finally feel like I truly understand CSS in a book I'm working on called "How To Debug CSS" [1].
It goes over not only the mindset shifts that have helped me gain a decent level of mastery over CSS, but also shows you how to solve the 50+ most common issues that you'll come across when developing with it. Like when you have an overflow on your page for example, and have no idea what's causing it.
One of the concepts I share in the book is on the idea of viewing HTML as a relational structure. Like a database. And how viewing it in that way helps you to better understand positioning (even with CSS). Because re-framing it in this way automatically gets you thinking about your elements, and the CSS that binds them, more holistically.
The most common way that people trip themselves up when working with HTML and CSS is by becoming myopic with regard to the specific section or element they're dealing with, and not seeing the whole forest so to speak. Making them unable to see why a problem in their CSS is happening.
Or to know what they need to do to create a certain thing in their layout.
A lack of a holistic understanding (how elements relate to other elements, and how CSS fits into this), and thereby view is what causes this.
My two latest articles goes into more detail re this:
I put some significant time trying to understand exactly what you’re going for and it seems like you’re trying to help people shift their high-level thinking, but it’s a lot of words and almost nothing to get my hands on. As someone who needs to try and work with things in order to properly understand them, this material just does not give me any “meat”.
These are not easy concepts to digest without visual examples. I will try to edit my posts with some concrete examples to get them to be closer to the book.
Tailwind is the first coherent CSS framework that makes that mixin design pattern work in my experience. Before, such designs usually drifted towards a spaghetti meta layer over regular CSS, creating an exponential mess. The added benefit of being able to go inline utility classes -> class names only when you want to (like when you've got a better view of the big picture) should not be underestimated.
If you defined a design system upfront you could do practically the same thing that Tailwind does except at a component level. On the flip side, it seems like even in Tailwind it seems like there are opportunities to create a mess.
I'm not a fan of the utility level of abstraction Tailwind is at, but I see the value. It seems wrong to view Tailwind as a CSS solution though, since in my opinion it's actually a design system solution.
So why not just use <center> and <font>? That was my immediate thought the first time I saw Tailwind HTML: it's the HTML1 tags, but they are now attribute values.
But you are correct. The idea of functional css libraries is to go back to putting presentational information in the html. And the justification is that it is a better approach when you are building a webapp with a component library.
That's a footgun if I've ever seen one.
In my experience it results in more consistent designs because everything must come from what you make available in your tailwinds config.
(but not out of line with your general conduct here, I suppose. I often wonder what people such as yourself get out of it...)
I find it more compelling than I expected.
The truth of the matter is that as much as the idea of separation of html vs css sounds good, it's so hard that I rarely see it done. Without constant vigilance, you end up with premature abstractions, things you can't actually reuse, and an append-only accumulation of CSS.
The dream sounds good but leaves all the hard details for you to work out yourself. And frankly, after over a decade, I remain unconvinced and ready to look for new ideas.
Breaking the rule with Bootstrap since it first came out never stopped me from building great things, yet trying to obey the rule slowed me down and had me constantly refactoring CSS. It feels like a cargo cult.
We've been pointing to CSS Zen Garden for 17 years as an example of the benefits, but giving everything a class so that you can address it from a .css file isn't the hard part, and that's all the garden shows. The hard parts are organization, maintenance, coming up with a unified strategy, playing CSS whack-a-mole when you change HTML, deciding where to define what, finding where you defined what, etc. The garden demonstrates none of that.