Well the point I was trying to make was to not do what the article says and name your class e.g. "green", but instead to name it something more sensible like "approved" or "updated" or something about the semantic nature of the style, rather than what the style actually is.

The reasoning is that maybe today it is just "green" but then what if one day the color in the CSS is changed, and it is not actually green anymore? You now either need to change the CSS class name everywhere, or leave it as "green" and confuse everyone because it is actually blue on-screen? This only scratches the surface - there are all manner of other considerations to think about (different display/print medias, dark/light preferences, HCM etc)

The core argument for tailwind is that it won't just be "make the approved text white on blue instead of white on green". Maybe you'll get "make the approved text a bubble with a checkmark on the left and make the title two lines where the second line is ..."

Frequently the change needed requires changing the html as well as the css (or maybe awkward advanced css). So you may as use a library/framework that lets you write an Approved component. At that point it's better to have the css and html for the Approved component in its own file as when you're updating the style you'll need to change some mixture of the html and css.

Without components tailwind is probably a bad choice.

Exactly. Classes, even for the simplest styling tasks, have been replaced by components.

Could you expand on this? Class names in CSS are just as important, if not moreso, than naming variables in typical programming.

Back in the late 90s and early 2000s, the dominant ideology is to use semantic class names, e.g. ".sidebar" instead of ".blue_bar" or similar. Essentially, don't describe how something looks with its name.

Even when building JS apps, I use CSS classes semantically with ".selected" ".menubar", etc.

I am interested in reading your philosophy on CSS classes.

The exception is when using a framework which isolates CSS at the component level, in which case your class names don’t matter anywhere near as much because you’ll only ever see them alongside the corresponding HTML.

Can't say I'm familiar with this type of webdev. How is the CSS isolated at a 'component' level? Is that not what selectors already do? I'm having trouble picturing how this is built or how it works.

Traditionally you put your template HTML or just HTML in one place, CSS in another, and JS in yet another, then tie them together via <style> and <script>. Are you saying there are frameworks that tie HTML and CSS together into the same unit? That is rather strange to me.

In such an environment, do people decide on no structure for their class names? I'd still want reusable CSS in such a situation.

It’s quite a common pattern in modern frontend frameworks. Each component includes just the CSS required for that component (plus any global styles). At built time, the bundler will generate unique class names for each of the HTML elements in the component and output an optimized CSS bundle matching those unique class names.

It definitely adds extra complexity in the build step, and the resultant randomly generated class names aren’t very nice aesthetically.

However, this approach allows you to read and modify the CSS, HTML and JS that affect a component all in the same place, instead bouncing around between different files. It also avoids the problem of naming (and remembering) globally scoped CSS selectors, and generally results in less CSS over the wire.