Hacker News Reader

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.

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.

[1] - https://gumroad.com/l/Debbg/z823cp8

I don’t personally mind the plug, but please give something concrete to help us understand what you mean when you say “holistic system of layout construction” and others.

Happy to expand.

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:

https://planflow.dev/blog/how-to-get-better-at-css

https://planflow.dev/blog/what-makes-css-hard-to-debug

I hope you understand when I say that your reply still does not contain anything concrete. Nor for the most part do the articles you posted.

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”.

I appreciate the feedback. The reason why it feels like this is because I haven't included any real CSS based examples here (which I do in the book) of what I mean.

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.

Awesome. If/when you do, try to reply here as I’m genuinely curious.

I didn't follow what was wrong with his Option 2 solution. A hybrid approach between that and Option 3, where you define a "base class" like he does in Option 3, but don't use it directly in the HTML, instead use @extend or @mixin to reuse it for the semantic classes that are styled similarly seems like the best of both worlds. A core "style library" like CSS, but you apply to semantic chunks in CSS instead of in the HTML.

That's actually the recommended way to componentize Tailwind using @apply once the styles grow too large and repetitive (no naming convention guidelines as far as I know, though). They got a big improvement in version 2 since now you can @apply styles with media rules and state modifiers like hover.

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.

I think the main advantage of Tailwind is actually the fact it's a preset design system, rather than it being utility first.

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.

> The truth of the matter is that as much as the idea of separation of html vs css sounds good

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.

...because they don't compose as well?

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.

for one thing, they are not responsive.

I read that article and it appears that his arguments for developing this framework boil down to: "what if you could create inconsistently designed pages easily?"

That's a footgun if I've ever seen one.

Tailwinds also acts a design system for your site, you have a set of paddings, margins, colors, font sizes, breakpoints, etc that make up your design system.

In my experience it results in more consistent designs because everything must come from what you make available in your tailwinds config.

The real problem is that tools like this appeal to people who dislike or not willing to learn or to do anything with CSS. And if we accept that tools are written by the authors to save their own problems, then we get what the tools like this are written by people who do not understand/like/whatever CSS. And the cycle continues.

That's just dismissing all of us who like Tailwind /and/ have a decade+ of experience doing all of this 'the right way' without bothering to properly argue. It's a very cheap comment.

(but not out of line with your general conduct here, I suppose. I often wonder what people such as yourself get out of it...)

What do you get out of ad hominem? You are the answer why people such as myself do not "properly argue".

Lol.