> It's basically the point of cascading style sheets
The "cascading" part is what makes it incredibly complicated. Keeping the "cascade" in sync with the actual markup is not a trivial task in teams with many people of different skills levels.
Not everyone is a top 1% dev, so we need easier and safer tools so that everyone can work and maintain a codebase.
> Sticking to proper class names and elements makes reskinning a breeze.
This is more easily said than done. It's like saying "Just don't write bugs". Every single project I find that has been built with BEM and similar patches after a couple years are just a mess and their CSS becomes "append only", as there's no guarantee that removing something won't break in unexpected ways.
You're just shifting work though. The commit will now contain 10000 non html structure changes to an html, phtml, whatever, instead styles to a CSS sheet. Might as well go back to doing inline styles. There's a reason we don't do that anymore.
This isn't the 90s. We all use file includes now. If you're working on a view file longer than a couple hundred lines, properly formatted, you're not abstracting enough or it's a one off marketing thing.
"If you're working on a view file longer than a couple hundred lines,"
Sorry, but this might just mean one file-include per tag if you use tailwind-css. The in-line CSS exceeds the HTML content by sometimes an order of magnitude bloating the page HTML to ginormous size.
"We all use 'cascading sheets' now. If you're working on a CSS file longer than a couple hundred lines, properly formatted, you're not abstracting enough or it's a one off marketing thing."
> The commit will now contain 10000 non html structure changes to an html
It's an acceptable trade off. Nothing is perfect. In exchange you're guaranteed those changes only affect this markup, and not some other li > ul > a whatever somewhere else.
> Might as well go back to doing inline styles
No, it is not. This has been explained thousands of times anyone says "tailwind is like inline styles". You can do responsive, you're limited to a consistent subset of rules, minimal output css file, caching, etc, etc. For example, here [1] is an explanation why it is not the same, but there are thousands.
By reading your answers I deduce you've not used it yet. And this is exactly what is being discussed here. Fanatics closed inward looking people will never like it, nor anything that defies what they've been taught for years. Like religion almost. You have to try it for real to see the benefits. It is not perfect, but the net result is very positive for a lot of people as you can see from the usage statistics. Just be a bit more open minded to new tech and give it a try. At least you'll understand why it is not the same as inline styles which is a pretty basic thing you understand after 1 hour of using it.
The "cascading" part is what makes it incredibly complicated. Keeping the "cascade" in sync with the actual markup is not a trivial task in teams with many people of different skills levels.
Not everyone is a top 1% dev, so we need easier and safer tools so that everyone can work and maintain a codebase.
> Sticking to proper class names and elements makes reskinning a breeze.
This is more easily said than done. It's like saying "Just don't write bugs". Every single project I find that has been built with BEM and similar patches after a couple years are just a mess and their CSS becomes "append only", as there's no guarantee that removing something won't break in unexpected ways.