[Kiro]

> So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.

Changing the CSS to apply site-wide changes sounds great in theory but after working in front-end since IE6, this almost never happens in practice. You're never certain how the styles cascade and indirectly affect things so you're afraid of changing the core CSS.

Styles isolated to components is a much more scalable approach in my opinion and then it doesn't really matter whether you use Tailwind, CSS-in-JS or scoped CSS (Vue etc).

[jstummbillig]

I do use tailwind and I find it terribly convenient for some things, but this argument still seems to mostly stem from too many people doing css who are not great at designing css and are doing things they really should not.

How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes? Of course I can then build more solutions around that. Or I can accept that good css design is hard, just like any good software design is hard.

[troupo]

> How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes?

How will you track that in `.hero-text__sticky-container--primary` vs `.text-with-image__card-primary`?

[jstummbillig]

I wouldn't. I would pick sensible class names. And then I won't care about what's inside specifically, because it's mostly dry.

And then it's still hard, because good css design is hard. Tailwind is not making that easier.

[xigoi]

> this almost never happens in practice

…so let's solve that by making it completely never happen?

[MrJohz]

Let's solve that by switching to a different abstraction that proves to be more useful. In this case, isolation-by-component instead of isolation-by-class.

I'm not the person you're replying to, but I'm in a similar position, and while I'm not in love with Tailwind*, it's successful because it's oriented around components rather than classes. In every project I've worked on, it has been far easier to manage the complexity of components over classes, because components link style and structure together, which usually end up very tightly coupled anyway. This limits the scope of the CSS you're writing a lot, making it a lot simpler to understand what any individual declaration is going to do - you know exactly where it's being used, you know exactly the HTML structure it's operating on, you can see exactly what it will do as a result.

* I use it a lot at work because it's very easy to get something written, but I find the pseudo-CSS DSL irritating if I need to write more complex queries. Something like CSS modules requires a bit more boilerplate to use, but you end up writing real CSS queries, which I find more natural. But this is personal preference.

[winstonewert]

Let's not spend extra effort supporting a theoretical feature that won't actually happen.

[xigoi]

It happens pretty often. I change the style of my websites this way all the time.

[winstonewert]

Ok, sure. But that's not what you were saying in the comment I responded to.

[xigoi]

Because you moved the goalposts. First you said that it “almost never” happens, then that it “won't actually happen”.

[winstonewert]

Its hard keeping track of different usernames on here.

From my perspective, "almost never" and "won't actually happen" aren't that different. Both indicate that the probability of success is very low. It seems to be, if the probability is already really low, is not worth extending effort maintaining it.

[Kiro]

They never said that. I did. You're talking to different people.

[bandrami]

> You're never certain how the styles cascade and indirectly affect things

Then your DOM is too complex. You're formatting a text document; that shouldn't get you in a position where you lose track of what cascades where. If it is you have a bigger problem than styling.