I disagree, I think most of these opinions I see about CSS are from people that haven't taken the time to learn it and particularly to understand the cascade.
Many years ago I did a very deep dive into the CSS specs as I was researching for a new implementation and it struck me as well designed for its purpose of separating style from the semantics of markup.
IMO the cascade is the exact problem with CSS. It worked fine when all it was dealing with was super simple documents with a few rules here and there, as soon as we started making applications the cascade causes endless headaches, and most modern methods of handling CSS like modules or libraries like Tailwind are made specifically to avoid cascade/specificity issues. Conceptually CSS is not really all that complicated, but in practice when you have dozens or even hundreds of CSS files for an entire app, it simply becomes a herculean nightmare to deal with and to wrap your head around.
As someone who works with many dozens of CSS files each day, I can say the problem isn't CSS. It's devs who are too lazy to document their work.
If everyone is working from the same spec/reference, it's fine, and you get consistent, reliable results.
When devs have to stumble around in the dark and end up reinventing the wheel every few months, that's when things go badly.
> devs who are too lazy to document their work
That's as bad a complaint as the one about cascading.
Your rules should be close to the object that uses them. It's really bad that CSS only supports global rules, and that is not a fault of the developers writing those rules.
When the !important comes out it's all over
It has been my experience that those that complained the loudest about CSS, expected to know it without actually studying or learning it. They already know a "real" language, so why should they have to study a "toy" styling language.
When it comes down to it, making a great looking and maintainable page is just as much work and planning as building a good backend codebase. Neither one just happens.
This problem is compounded by CSS kind of overlaying HTML in a way.
Lots of "real" devs treat HTML with similar "I don't need to really learn this toy markup" kind of attitude. The worst CSS issues I've ever had to deal with were often caused by horrible markup that was impossible to consistently style.
Basic stuff like how to make a good `<form>`. Putting `<label>` elements next to your `<input>` elements, or making sure the `for` and `ID` attributes are set. Hell, even using `<label>` instead of some `<span>` they threw a bunch of random framework classes on.
I think developers nowadays being coerced into being a jack of all trades, master of none contributes to CSS being the least studied and practiced by full stack devs. Such devs would also be much more inclined to put their time into, for example, learning and practicing databases rather than improving their skills regarding UIs, and for webdev that means skimping on CSS while just doing the bare minimum, mediocre thing to get it working.
I is certainly true for me that I didn't take the time to learn the intricacies of CSS behavior and I still think the cascading properties are the worst feature, namely concepts like specificity. It is hard to keep a mental model of styling rules and at some point it is just degrades to trial and error.
Nobody came up with a better alternative though (apart from the many dialects that transpile to CSS again).
In 2025 when starting from scratch all you really need is flexbox, css grid, and the box model and that will get you like 99% of the way on most layouts.
Specificity is really just
* ids take priority * the highest number of specified classes, and if there’s a tie it’s the first one specified * the highest number of types
The only problem is that most paths in frontend development say “slap a class on an element” and call it a day but you do need to be intentional about it and only specify what you need
What about CSS layers[0] doesn't solve your specificity issues?
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@layer
Video games became a lot better when developers stopped saying, "You just haven't taken the time to learn it and don't understand it", and started saying, "That's my fault for designing it that way. Let me redesign it so that it's accessible to everyone in my target audience". I wish programming languages would be humble enough to do the same (although many are!).
The problem here is that it wouldn't matter if you made a better language for styling web pages, because you have no vector to get that language included in browsers; and even if you did it would take years for it to get enough market penetration for you to rely on it as something you can deliver an app in. So, you'd end up with some horrendous compatibility layer that compiles everything down to nasty CSS anyway.
Same problem with Javascript. Here we are compiling Typescript down into it... and running JS on the server with Node in order to avoid the classic impedance mismatch we all had back in the day writing backends in PHP etc.
Feels like the real solution would be to allow browsers to become more flexible with language implementations instead so we can make more progress. WASM might be the ticket there?
All that complexity is a trap. It creates a need for people that have spent the unreasonable time to grasp a poor design, and then they have the secrets that others simply do not have the time to waste learning yet another poorly designed reindeer game. That complexity eats time, energy and is pointless. CSS is a shit show of poor design, poor documentation, and secrets.
What secrets are you talking about?
All the edge cases.
Do you have any concrete examples?
How's about the very existence of different layout engines, which can all be in-use at once on the same page?
So, what is your proposal?
Throw away the front-end of the Web and start over with a system actually designed to facilitate graphical applications instead of delivering styled documents.
HTTP can stay, and HTML/CSS can stay just like PDFs for delivering a document, but when it comes to UI components, we should be able to have things as fast and performant as e.g. RedLang / Processing / Enlightenment DR17 / etc without every developer having to shovel megabytes of shim-ware down to the client.
That's a good solution in a perfect world. But that's magical thinking. What's a real solution?
We have a plethora of native frameworks for building UI-s. Some of them are quite well designed. And yet the Web front-end has won against all the UI frameworks designed specifically to build UI-s.
That’s partly due to reach, though. The combination of the browser coupled with Electron eating away at those native UI layers means it unfortunately makes little sense to bother with alternatives, even if the alternatives are better.
I.e, the GP is trying to argue one thing and you’re kind of going down a different tangent.