I write a lot of CSS and I would probably disagree.
CSS has no console.log() for debugging, CSS often fails silently, and the demos in the link are more or less (albeit pretty neat) hacks, but don't use CSS features in the way the specifications intended.
Yes, but with the browser debugger you can step through the JS code and visualize what it is doing. How can you visualize what is happening with CSS, short of debugging the internal browser code ?
Easier to find the bug harder to fix I think. The problem is CSS has a global scope - you change one thing and breaks the whole site's layout. With javascript usually code affects more specific areas of the site/web app.
> 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.
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.
Although IMHO it makes logical sense to put the logic for the modal windows in the JS, not the CSS. And definitely easier for maintaining it.