You are using the word "proper" twice as to indicate that it's well established what that means in terms of CSS. Adam felt that the idea of semantic names wasn't really working. This was an itch that I had myself without ever articulating and I think that the popularity of Tailwind shows that many developers felt/feel like that.

> You are using the word "proper" twice as to indicate that it's well established what that means in terms of CSS.

To say "proper classes" doesn't imply anything about CSS. Classes are a markup concept. The class attribute predates CSS; CSS's selector language lets you target "class-ified" elements, but it's not like classes were invented for CSS.

I do agree, it's easy to abandon classes altogether. It's also a bit concerning that newer devs are starting with Tailwind. At the same time, I think one should be able to notice that certain styling is just getting repeated everywhere and abstracting it out makes sense.

What I actually like about Tailwind is not that you don't have to create classes at all, it's that you don't have to do it for things that don't need it. My old codebase was littered with hundreds of classes doing the same set of styling — padding, margins, flex-box stuff. That's the biggest thing Tailwind helps with.

That may be an issue with inconsistent design elements on your site, then. Simplify, reuse as much as possible, simplify again, repeat.

> it pulls you out of the habit of using proper classes and such

What's "proper classes and such"? You mean hundreds of increasingly specific and non-reusable BEM abominations like `.hero-text__sticky-container--secondary` that no one remembers and creates new ones?

Oh the joys on having to edit a website that was made (by myself or someone else) years ago before Tailwind. It takes at least a few hours to figure out exactly what all these class names actually do, and you are still never sure that there isn't some random lines in the CSS files that will prevent the style from changing like you hoped.

No, that sounds like a tangental problem born of inexperienced developers and/or poor communication.

There are many, many, many cases where communication is not possible because who is working on the code now didn't exist when it was written (unless you want to take the time to document out all of your CSS and hope that everyone who touches it follows that documentation exactly). A new team taking over, a new agency updating a website for a client that was made by another agency, a new developer being brought on, etc.

Sure. That's not a problem exclusive to CSS, though, and I don't see how it's one fixed by allowing bad coding practices.

> No, that sounds like a tangental problem born of inexperienced developers and/or poor communication.

I've yet to see a single project to not devolve into a mess of class names. Not only that, but a mess of class names with significantly repeating boilerplate, intimately tied to specific elements.

Proper classes would appear rather more like `class="secondary sticky container hero-text"`* in the markup. So no.

* or `hero text`, even (sans hyphen)

Have you ever jumped in on a project with hundreds of "secondary sticky container hero-text" all over the code base? It is a woeful few hours (at least, maybe day or two) of cross-referencing all of these "semantic" class names to their definitions in CSS, and even then you are never truly sure if there is another rule overwriting your changes somewhere else in the CSS. And good luck if more than one developer has touched the code since you last saw it.

As I replied in a sibling comment: https://news.ycombinator.com/item?id=36635382