“Anything else is probably misuse” is simultaneously true and brushes away all the realities of front end development.
The cascading is pretty nice actually. Think about using CSS vars... you can dynamically theme apps because of the cascade, by changing just 1 class. there's other nice attributes, and it's true it requires discipline. Just not nearly as much as you imply
But with the cascade, call sites are implicit — and removal, for better and worse, doesn't cause a hard error.
All it takes is a single rogue engineer or product manager to mess things up. And then cleaning things up later is difficult because of all the places that have to be inspected.
That's completely impractical[0] given inclusion of 3rd-party code and no enforceable standard for imposing step 2 on other developers.
(Web components now exist to facilitate this, but of course, web components are relatively recent; most of CSS's history did not support this 4-step process).
[0] To be fair, maybe completely is too strong an assertion. I've seen something like it done... A compiler rewrites the CSS selectors and the CSS classes to create a sort of top-level namespace by prepending some garbage per module so that no component can accidentally reference another component. It's not great for debuggability (about as much fun as having to deal with the actual entrypoint names in the binary for constructors and overloads when debugging C++), but it gets the job done.
I mean, I just prepend all my component class names with my library name or a shorthand acronym, so 100% of my styles are like `.NawgzInput {}` or `.NawgzGraphNode {}`
I have never seen the limitation to this approach (i.e. the ends of its ability to scale), so long as you don't pick a super generic prefix. So to hear you assert this approach is "completely impractical" to someone who has used it to build their own component library that every application they build is entirely comprised of.. rings hollow
That's the best I think we have now. It's not good (i.e. decreases readability), and it's not universal (there are definitely component frameworks out there where the classes are just named "table" and "button").
Except it's incredibly easy to debug and avoids most of your complaints about the solution.
Anyways, fair enough, I can confess that there is probably another ideal world that has better viewport styling. But CSS is giving us incredible flexibility, and just like JS, its warts can be worked around very easily and deliver you a powerful, useful, simple set of capabilities.
"Global all the things" seems to clash with "component".
Its more of a belief rather than knowledge at this point.
I'd be interested to hearing a good answer as to why one wouldn't use !important on a modifier class such as ".padding-20" or even something like ".full-width".
Surely the problem lies with your html composition if either of these classes are being used on an element that does not need them?
Over time, accrued wisdom has turned into a rule of thumb such that Grumpy Old Developers sit around the fire with Young Energetic Developers and say “ya know, child, never use !important, it’s bad design.”
The web development industry is getting mature enough to even have this kind of wisdom, which is wonderful, even if (like “wive’s tales”) the principle is overstated.