[ehnto]

They might mean a system like BEM, where they are semantic in that they represent concepts tightly coupled to the HTML and what it's used for.

    <div class="product">
        <button class="product__add-to-cart">
        ...etc

BEM is a good example of what Tailwind is a counterpoint to.

[e12e]

Nothing stops you from layering BEM on top of tailwind via @apply - although I'm not sure if that's a good idea. Maybe if creating a full, custom, design-system using tailwind?

[omnimus]

Although the Tailwind author hates @apply and says they shouldn't have put it in the tailwind in the first place (mainly because it's a hard feature to develop - i wouldn't be surprised it would be removed). I think going tailwind only is bad too because you loose many of the nice functions of CSS like theming/cascade.

So i think using utility classes/tailwind for base/layout and still using named classes where it makes sense (like common reusable components, hover hiearchies, transitions/animations) is most practical approach. And using BEM as convention for the named classes is not a bad idea - certainly better than no system.

[e12e]

> Although the Tailwind author hates @apply and says they shouldn't have put it in the tailwind in the first place (mainly because it's a hard feature to develop - i wouldn't be surprised it would be removed). I think going tailwind only is bad too because you loose many of the nice functions of CSS like theming/cascade.

I'd say that dropping the cascade, along with namespacing "classes" (through the build-step) is the main feature of tailwind. It's a departure from CSS - I don't think I'd recommend to mix and match.

I like CSS, but I also see how it's a complex tool that's often used poorly, even by experienced developers.

As for themeing - I'd say that is well supported within tailwind.

[omnimus]

Typical basic example where tailwind fails is styling text and i don't mean styling html generated from user markdown. (that is given - impossible to do with tw)

When you have any text on page like a heading - tailwind approach is for you to set ".text-xl .leading-tight .tracking-tight" ok fine. Your designer is then like. "Yeah on mobile the fontsize must be much smaller and thus tracking+leading bigger" (because these 3 are tightly related) then he will also want the heading even bigger on big screens (and decrease tracking+leading). Suddenly you are juggling 9 classes that also have some fixed value. So you look into Figma and see that on mobile the leading of this style of heading is 1.27. On laptops its 1.14 and on big screen it's 1.035. So what now - will you change the design or will you add new utility classes specifically for this heading?

So you realize the best approach is to create one class .text-heading-1 and use css - that solves all the issues and it's super easy to change moving forward when you need some fine grained responsive adjustment.

The great thing about TW is that it's very fine grained in html but on the other hand it's bad at being explicit and precise like css is. I think the reason people like TW so much is that huge chunk of web work is layouting. Flex here, justify there and add gap. No more pain to target/name element just because you need to add margin and flex.

Theming is OK to some point (like making dark version) but if you need to make broader changes between multiple themes it just crumbles.

[e12e]

> Suddenly you are juggling 9 classes that also have some fixed value

In my experience, devs using tailwind will happily wait until there are 20+ classes before refactoring - on the surface this seems insane - but if all you're editing is single, re-usable components (eg: "text on a page" is in a custom "article" component) - it's no longer quite as crazy.

> Theming is OK to some point (like making dark version) but if you need to make broader changes between multiple themes it just crumbles.

You wouldn't make css zen garden with tailwind - you would make such sweeping themes at component level, where you can change style, behavior (js) and markup all together.

Again - tailwind isn't for document styling, but for building applications - that happen to feature html and css as implementation details.

[omnimus]

> Again - tailwind isn't for document styling, but for building applications - that happen to feature html and css as implementation details.

And yet it's app developers i know that hate it and don't want to use it (they already have single file components). But agencies making super custom content websites seem to be all over it. https://www.awwwards.com/websites/tailwind/ These websites are css zen gardens if anything.

[ehnto]

I would say that'd be a Tailwind anti-pattern, since Tailwind exceeds by trying to do away with cascading, and BEM is an attempt to componentize CSS but retain some cascading.

Also, if you handed me a project with that approach, I would run for the hills! How would you decide when to use BEM styling and when to use the tailwind classes? It'd be a nightmare.

[omnimus]

Use tailwind as much as possible until you feel like you need a class then use BEM for the naming/organisation. It's actually pretty practical system - with headwind the non TW classes sort to the front so you can immediately see if there is something more in css.

The resulting css you end up with is usually super light only with special things, edge cases, hover groups and stuff TW just doesn't handle.

[e12e]

If you ever use @apply,you need to come up with a name. I prefer a few @aplly classes to meaningless clutter of tailwind detailed styles.

You could of course have a policy to never refractor - but then you might need to enforce alphabetical use of tw classes to more easily keep styles in sync accross your codebase?