[AlienRobot]

The problem is not CSS per se, but HTML.

HTML was designed to be a document language, like a PDF, but worse because it has no absolute positioning so text just changes shape when you change the width.

Almost every website does NOT follow the "document" paradigm but an "app" paradigm with navbars, sidebars, panels, etc. None of these things fit the model HTML was specialized for.

If HTML/CSS were for those things, we would have had scoped rules for classes day 1.

[exogen]

Exactly. The problem is the platform has not kept up with the way it's used in practice. Features are added with strange priorities, and obvious blind spots ignored, leading to it being under-developed in many areas, and over-developed in a handful of others. We get vendors working on weird stuff like Web Bluetooth before obvious things like element anchoring (finally, yay... but still just a Working Draft) and reliable element position tracking (still a huge pain).

There are still no affordances for many things, so people have to invent their own solutions.

[AlienRobot]

I've always had the impression that the "problem" at its crux is that people worked around HTML/CSS limitations. A recent article about IPv4 gave me the same feeling.

When faced with a widespread standard that is sorely lacking, instead of patching the standard globally, people come up with their own workarounds. This accumulates until the whole thing becomes a conceptually "pure" core under a transfigured mess of patches to make it work the way the modern world needs it to work.

For HTML, I feel that PHP and Web 2.0 did unspoken harm to it. A lot of things that are done by server-side rendering (and afterwards in client-side rendering) should just be features built into HTML from the start. Templates, themes, widgets (panels), components, etc. Now we have "templates" and "components" but neither of these terms mean something in HTML that actually does what you would expect from a templating language which is critical of almost every website.

I mean, am I crazy to think that if you have 2 webpages that share the same navbar, you shouldn't need a build step or special program just to handle this use case in a way that is maintainable? It should just be built into HTML? Javascript isn't a solution to this because that means the website is unusable without Javascript, and that sounds stupid. You need to enable Javascript just to have a navbar? Or you need a whole SSR just to avoid having to copy-paste the navbar? Or a build step? How did we keep using this thing for 30 years?

I feel like because developers could just do this with PHP/JS, these basic features never made into the pure HTML language.

The weird thing is that these languages still get features, just not any features that makes it more powerful at building simple things. HTML has video, web assembly, CSS has animated fonts. But you still need a separate program if you want the same navbar everywhere.