> The problem is CSS has a global scope - you change one thing and breaks the whole site's layout.

I know what you mean (I tried fighting the default Plone theme before the littering of various instances of !important got refactored out) - but it's also deeply ironic. It's Cascading Style Sheets - if you don't use the namespacing - you will have a bad day. Remember how bad javascript snippets based off of tweaked code that some old version of Dreaweaver had injected to a project some generations prior to the one you were working on was?

Just as people "programmed" javascript without learning the language, so people did with CSS. And not just "hammer it with !important until it stops resisting" either.

Simple example: today, if you want poor man's stand-alone component ; stick the html in a div (or other element) with a class of Mygreatcomponent, and style from there with direct parent/child-stuff. Sure, you need to do manual namespacing, but even if your project is huge, you can grep for class='whyisitallpinkComponent'.

"The problem is CSS has a global scope". CSS can be written in a way that it affects only specific parts of the site/app. "you change one thing and breaks the whole site's layout". There are use-cases when you want changes to reflect across the entire site and CSS can be easily used to achieve it. (Ex: changing color of buttons). Javascript can also break the whole site's layout. It just depends on what code we write.

I experiment with scoped CSS - where styles and even responsive conditions are tied to a specific element on the page and not the page as a whole.

This means you I'm able to retrofit old sites with new code with zero fear that the code I'm adding can affect anything else previously on the site :) It's also handy when building new stuff too.

If you properly modularize your CSS the global scope no longer remains a concern.

the thing is that we don't always start working on sites from scratch. more often I have to clean up someone else's mess or my own that I made months or years ago. in that case I'd rather debug javascript than css.

Yeah, I think it's a lot easier to fix shitty JS than it is to fix shitty CSS. Every job I've had, I've fixed more than I build. If it's a 5 person startup, I'm iteratively fixing my own shit as the product pivots. If it's 30 people, I'm fixing code from that one idiot that interviewed well and turned out to be impressively terrible. If it's a 10,000 person company, I'm fixing shit from that entire division that wasn't properly managed.

On the contrary, I think it is a lot easier to fix shitty CSS than shitty JS, because CSS is not run, but specifies attributes. This makes analysis static for the most part; race conditions and similar bugs usually do not occur.

my entire career in 2 lines