[unculture]

It’s more like “i.e. shall we inline all our variables” / avoid naming things at all.

Adding a name for something is a weighty task that’s orthogonal to the task at hand. If you can avoid the name without losing understandability then it’s a win.

The other side of that coin is that if you add a name it has to be worth the effort.

In CSS, a number of techniques developed over the years in response to the maintainability challenges of even well thought out, traditional good practice CSS in large projects. These techniques (eg. BEM) required class names for almost every element you need to add styles to. This was to avoid long selectors that a) are hard to understand, even for experienced CSS developers and b) are tightly coupled to and generally not co-located with the HTML.

Tailwind gives us away to avoid those having to choose those names, which just took a long time and lots of conversation if you wanted to get them right.

Yes, it’s literally in the HTML so it’s coupled, but it’s co-located. The maintenance story is much simpler than with BEM and much much simpler than with trad CSS. Lower effort for a better long term result - it’s a win.

[zelphirkalt]

There is a downside to not naming things: All the concepts are in your heads and not in the code. It's not self-documenting at all. No one names that div or section or whatever tag via a readable class name, so any future reader will not know, that that might be a concept bound thing in the site. Styles are just applied until it works, which leads to a mess. New web dev comes in and gets told "That font is too big!". New dev opens the inspector, looks at HTML element soup. Hurries to the code, replaces some styling on that level of nesting in the HTML, but does not understand the concepts of the site at all, nor that there are probably 10 other places, that now need change.

A well thought out class name would have helped understand, that new dev is actuall editing something, that is part of a group of things, which all have something in common.

Naming things is hard, but finding good names is worth gold. Avoiding the hard parts is not going to be the solution to all problems. We would all be working in some kind of modern version of lambda calculus, if naming wasn't important. There are good reasons, why we name things. To convey meaning and convention. Not naming things hides these and makes them implicit, instead of explicit.

[unculture]

There is a line to be drawn somewhere. If you set your naming level too high, then it's not clear what you're doing in the details. If your naming level is too granular, then you start to lose clarity because you can't see the wood for the trees.

Regarding the problem of a developer new to the codebase being told to change the text size in a specific place; Tailwind works well in this specific situation.

At the beginning of your project, you will have chosen a (or accepted the default) text size scale. The new developer will probably choose the next largest step in the scale and step back. The new size will be in harmony with the rest of the project because it matches the scale. If this specific element is repeated elsewhere in the project, then it will be part of a component and all instances of that component will receive the change.

The right place for a considered name in this example is at the component level.