Honestly I say the reason it’s sad is because of the idea that CSS promised something it couldn’t deliver. The sad part isn’t that people gave up on CSS, the sad part is that people believed it could work this way in the first place.

Writing CSS stylesheets by hand is like writing HTML pages by hand. It just doesn’t scale, and you run into a million tiny problems every time you change something in a medium size project. So for HTML we use templates and components. For CSS, we want the CSS for a component right next to the component itself in our VS Code window, so that actual humans have good insight into what styles will affect a particular component. The alternative—keeping the CSS separate—requires its own set of tooling to plug the holes, like all those fancy web developer tools built into browsers these days.

I always thought the approach of returning XML from your web server and having it refer to an XSLT stylesheet made the most sense. Unfortunately, XSLT is a very verbose and clunky style language. If it had been a better language, I think it could have been a good solution.

I think component systems like React are the closest we have to achieving that dream. This is why Vue, React, Angular etc. all look something like writing your own tags and then implementing them in terms of, eventually, standard HTML tags.

You can even swap out the web browser front-end, to an extent. I know that some mobile apps are done this way.

It is only sad when you have not worked on a medium sized website/webapp.

For a small document like css zen garden where the goal is to produce a diversity of design without changing the html? css selectors are perfect. But how often is that the goal of the UI team?

The goal of a ui team is to have a consistent ui that is easy to change. Components helps with consistency. It also helps in separation of concerns: you can have someone writing the component library and someone else using it.

The goal of a ui team is also to minimise the amount of ui bugs, and the amount of ui code. If you let people go wild with css selectors, you end up with badly scoped class names and very painful integration phases where selectors breaks the ui across the whole application. When fixing bugs people are too afraid to remove anything because it means that they have to test a huge scope.

The trend I see is not spaguetti (except in places that don't care). It is the use of a very restricted type of selector: .class_name. Some people use css BEM or functional css and write those names themselves. Some people use a css in js library that generates them.

We have started adopting css BEM two years ago and now we are considering using a css in js library. I had to manage a css library update recently and 90% of the issues were in place where people didn't have this kind of methodologies.

Just like with programming you have to limit scope. And avoid using global scope. Its fine to have a "private" base style for components. The power of CSS however is that users can overrule those styles. Its however important to organize the css in a cascade and not have rules for the same element spread out all over the place with !important everywhere.

You used to see CSS frequently used by hobbyists making personal websites. As a result, you'd see a lot of posts about what cool stuff they could create, their opinions on how to structure things, semantics, etc.

Now these same people are mostly doing it for the paycheck. And there are a lot of new people doing it as well. In fact, dozens or hundreds of authors may be maintaining the same stylesheets. You just have to get your changes in.

People get older, begin to care less. The web has surrendered to commercial platforms. It's not as exciting.

Even with the most powerful CSS methods, you simply cannot completely separate the structure of the HTML from the layouting.

It's better to give up on this ideal right from the beginning than to build something that ends up getting complicated with work-arounds and edge-cases.