CSS: The bad bits (and how to avoid them) - Joe Forshaw

The more I use CSS, the more I think it’s an absolute wild wild west. It’s mature, ubiquitous, yet lacks basic, common-sense features that come as a given in other similar tools. After working with several modern MVC web apps that have well architected back-ends, extensive test coverage and good documentation, I often find the stylesheets to be giant steaming piles of spaghetti garbage. … ## 1. Global scope # My first and biggest qualm with CSS, is that any style declaration can change any aspect of any element on a page. This is super powerful and great if you’ve just started dipping your toes into web, but for bigger sites, more often than not, it’s very dangerous. Almost all front-end developers at one point in their careers will add/update/remove a style, only to find it accidently leaks into some other section of another page. I think this is the most significant issue with CSS. It makes any concept of modularity very difficult. Tomorrow a developer could just stick in a few `!important` tags and scrap your nicely encapsulated, reusable widget. ``` .blog-post { .title { font-size: 2rem; # Grrrr, styles leaking everywhere h1 { font-size: 5rem !important; ``` … This is better, but it isn’t a fool proof solution. It only takes one careless style to take you back to leak hell. One tight deadline which forces you to make some questionable compromises (i.e. hacks). If you told any back-end developer that they had to use a programming language that gave all variables global scope, made every object’s internal state visible, let any other developer override their code, they’d probably resign on the spot. But that’s the insane reality of CSS development. Everything’s up for grabs. Immutability? Pfffshh. … ### Best workaround # Don’t participate in the race to the bottom. In general, make sure your styles aren’t too specific. - Try not to use `!important`(sometimes you have to when working with 3 rdparty embeds). - Don’t style on IDs (very specific). - Use class names (unspecific). - Avoid including descendents in style selectors as these will bump up specificity. * With SASS/SCSS, nested styles compile down to descendent selectors, so don’t nest. - If you’re using BEM, you’re already following these rules. 👍 … ## 5. z‑index # When z‑index is causing headaches, a common solution, the nuclear one, is: `z-index: 999999`. Once this happens, chaos ensues. Anything that needs to appear above it in the future will likely include an extra 9. I think it all starts to go down hill due to a lack of context. Because z‑index rules are specified individually across all stylesheets, the relationships between them isn’t clear.