That resonates with my view, well enough. Most of my complaint with CSS is not the idea of having a style sheet. I'd more complain at how so many people try to get the natural flow of the document to rube goldberg into the layout that they want. That and the "unrooted" nature of most styles. It can be powerful, but usually is just a mistake.

So, I'll make a concession here -- I definitely don't think CSS is perfect, and two things that are not great about it is that I'm not convinced specificity is all that good and the focus on using native elements for style names is a big trap.

When I switched to using BEM, CSS immediately became like 3x easier, especially on large projects. And there's no downside to style overrides or user customization or maintainability, there's no 3rd-party library to install, it doesn't require me to write a single line of Javascript. All I've done is change how I name classes. For users, BEM-style CSS is easier to do user overrides on through custom stylesheets than the traditional CSS that uses semantic naming.

And I do think that's a big weakness of CSS and we might have set a bunch of people up for failure by teaching everyone that the "proper" way to use CSS is to write

  main section p {
    color: red;
  }

Nah, that is asking for trouble, you will end up with soup and you will have a terrible time trying to figure out what styles are applying to what elements. Instead, use

  .Article__Paragraph {
    color: red;
  }

and all of a sudden you won't hate refactoring as much and doing style debugging in the browser will be way nicer, and when you open up your dev tools you'll see component names instead of div soup, and you'll be able to instantly grep for the code you need to change for every single style alteration you make.

Not that BEM is the only way to do that kind of thing, it's just the version I tend to evangelize most commonly. But the big thing is, use stylesheets, definitely, but don't do a bunch of nested rules that are targeting native DOM elements. We shouldn't be teaching people to do that.

Basically this is my argument for the self inflicted pain of CSS. Worse than

  main section p {...}

is when you have people start with stuff like

  p {...}

and then they start to have all sorts of woes when they realize they don't have any way to specify this particular paragraph is the one they meant. So then you end up with people being forced to use nth child selectors to hit the intro paragraph.

Then they start to think, "I want the first section to be the abstract." But should they add an "h" element to use the header to indicate a new section? Or should they make a giant container div to do the same? Why not both for different reasons throughout the same app? :D

Exactly! Zero argument on this, you are completely correct.

I do think escape hatches are important, so I'm not going to say that CSS shouldn't support referring to element types directly, that would be way too far for me to go. But...

I generally don't use direct element selectors at all when I write CSS now, and I think that teaching people to start with stuff like p {...} causes just so many problems for exactly the reason you're talking about. People are drawn to it because of that idea of everything being semantic, but styles like BEM are not any less semantic, they're arguably way more semantic because when styling you're now thinking about what an element is, not where it's positioned relative to other elements. And you get to say what an element is and what its purpose is publicly in giant capital letters in the class name that anyone can read.

Honestly, maybe I deserve a little bit more of a self-callout here because I've been kind of dismissing some of the annoyances and thinking, "this isn't that bad, you're just saying what a component should look like, yes there's concepts to learn but it's not like CSS rules are harder to learn than something like Rust" -- but part of that is me forgetting that it is significantly harder to just "say what a component should look like" when there are 5 CSS files all referring to the same elements, and so changing a rule suddenly doesn't take effect because some other CSS rule is more specific, and then changing anything suddenly breaks a completely separate part of the page over someplace else because it shared a selector.

It's like taking a function and arbitrarily splitting it across 5 different files with no rhyme or reason about which lines go where, and there's no way except by tracing the function to figure out which lines of code are ever getting called. And that's the default way that most people are taught to write CSS.

People went wild over scoped styles with web components, and to be fair scoped styles are really nice, but I never felt like they were essential for any of my projects. But if I wasn't using BEM and if I wasn't thinking about my styles as being attached to components even for completely static documents with no Javascript... yeah, scoped styles would probably be a lot more important to me :)