7 ways to tell your css has gone mental

I work on big sites almost exclusively so my techniques are all about wrangling tens of thousands of lines of code into a few thousand. When deadlines loom or you work with a staff of various skill levels css begins to loose its organization.

So here are a few things to look for to know its time to reorganize your code.

  1. When !important becomes a way of life. When the only way to get a piece of code to to work is to wrap !important to the end of every line, your css has gone mental.
  2. When you scroll through the style definitions and see !important sprinkled liberally throughout the styles. Your code has definitely gone mental. Seriously if there are so many clashing definitions that only an !important can solve it you need to look into taking a BEM and SMACSS approach and flatten your definitions.
  3. If you need to change a color and have to do a find and replace to get to them all your code has gone mental. It is time to preprocess your css. I prefer Sass just because it has super powers, but Less is almost as good. Preprocessors allow you to use variables so you can keep all your definitions in one place and reference it everywhere.
  4. If additions to classes end up in a jumble at the end of a file it has gone mental. Choose a technique that makes it easy to find the classes that you need to change. Preprocessors allow you to break your styles into as many files you need to keep your css organized. Sass to the rescue again.
  5. When style definitions are nested five levels deep you know your code has gone mental. Use BEM naming conventions and ideas to flatten your styles and give all your elements a class name.
    Distinct modules should be able to live on any page in any location and maintain their styling. Doing this will help break your code down into manageable chunks.
  6. When the the slowest part of your site is how fast it renders the styles you know it has gone mental. When styles get too complex it can slow down the site and leave it hug half broken till it finishing going through all the exceptions from the nested rules. Again flattening your rules and proper naming would go a long way toward resolving that. BEM has helped me organize my code into something a bit more manageable over the long term.
  7. using # over . will drive your site mental. Specifity will ruin your day ,but adding IDs among your definitions will just overpower any classes and make fixes that much harder. Avoid them on anything but page structure. Using IDs on modules may be moved to new pages will just confuse things when duplicate IDs start showing up on the same page. It will render but it may break js and cause conflicts when there is an ID and a class, but you are only working on the class. Consolidate styles into just the classes helps that.

Here is a great talk about organizing CSS using OOCSS, SMACSS and BEM and SASS. OOCSS has been absorbed into SMACSS and BEM principles so it isn’t mentioned as much any more.

Posted by Jason McAlpin

Jason Mcalpin is a full stack developer and game designer. Jason has been programming for over 30 years from the days of punch cards and COBOL. Things have progressed since then and continue to move at a furious pace and Jason explores all of the latest trends in the field.