3 warning signs to help you save your CSS

I love avocados! I like them as guacamole, spread on a bagel, or sometimes I’ll even just eat them on their own with a spoon. On the other hand I absolutely hate buying avocados because they’re not usually ripe at the store and they continue to stay that way until all of a sudden one day they’re too ripe.

CSS is a lot like an avocado because after a while it can suddenly get very difficult to maintain, especially when there are multiple people involved. As more and more CSS gets written, things can spiral out of control and an overwhelming feeling can sink in pretty quickly.

If you recognize when your CSS is approaching a state where it’s becoming more difficult to maintain, you’ll be able to course correct with less difficulty and refactor your code to a better state. Following are some of the warning signs that you should be aware of—catch them early and plan accordingly!

Warning sign #1: Lots of small inconsistencies

Inconsistencies make code less predictable. While this might not sound like a big deal, consider that the less predictable your code is, the more time you’ll have to spend verifying that you used it correctly. For example, if some of your CSS classes are written using spinal-case (letters using the same case with words joined by hyphens) and others are written in snake_case (letters using the same case with words joined by underscores) it’s much easier to mix the two up when writing HTML. If the styles don’t appear the way you’d expect, then sure you could just try the opposite, but over time this can get really annoying. Even worse, you might end up with two classes with the same name that use a different convention to style things differently:

        .product-grid {
          border-bottom: 1px solid #F5F5F5;
          border-top: 1px solid #F5F5F5;
          display: block;
        }

        .product_grid {
          background-color: #F5F5F5;
          border-bottom: 1px solid #333333;
          border-top: 1px solid #333333;
          display: block;
        }
    

Making a conscious effort to keep your CSS more consistent as you write it is a surefire way to prevent future headaches. Subtle things like consistently naming classes in a way that promotes code reuse, ordering declaration block properties using some convention, and even deciding how to declare colors (three-digit hex, six-digit hex, RGB, HSLa) will make your code more predictable and easier to scan, which will help you detect and work through bugs easier.

Warning sign #2: Tight deadlines and changing requirements

Tight deadlines are nothing new and sometimes they can come out of left field. These deadlines can result in people getting in the mindset that they need to “just get it done” even if that means writing code that they are less than proud of. As a result, CSS can be duplicated, given class names that aren’t properly thought out for reuse, or be made very brittle using overly specific selectors.

Changing requirements can be just as bad as tight deadlines and might even contribute to making a reasonable deadline more difficult to hit than expected. Even worse, if something changes drastically enough, dead code—code that exists but isn’t used—might be left behind, which leads to a cluttered code base.

While the rhythm and flow varies from organization to organization, it’s common for off-the-cuff estimates to become the basis for project schedules. When asked how long a given task will take, you could blurt out whatever you think is accurate at the time, but it’s much better to perform some due diligence and add a reasonable amount of time to use for refactoring.

Warning sign #3: The cascade is no longer your friend

Have you ever written CSS expecting to see one thing only to be surprised and frustrated when your browser renders something completely different? We’ve all been there and there’s nothing worse than constantly fighting the cascade, which is the algorithm your web browser uses to apply styles defined by CSS to HTML elements. When you and the cascade have differing opinions about what something should look like, you know it’s definitely time to do some refactoring.

The good news is that the cascade applies CSS based on selector specificity and order. Selector specificity describes how precisely an HTML element is identified in your CSS by a selector, whereas selector order describes where in the stylesheet your selector appears; selectors with a higher specificity take precedence and when two selectors have the same specificity, the one that appears later in the style sheet wins.

On the plus side, when you write CSS expecting one thing, but get another, you know it can only be one of two things: either the selector you used has a lower specificity than another, or it’s in the wrong place. However, this could be indicative of larger issues:

• Have you been writing selectors that generally have too high of a specificity?
• Is your CSS disorganized, forcing you to add all new code to the end of your existing stylesheet?
• Are you using third-party code that suffers from either of the two previous issues?
• Does your CSS abuse the use of !important to apply styles?

If any of the above is true, then you would definitely benefit from refactoring your CSS. Whether we like it or not, the majority of our time is spent dealing with existing code and unfortunately even brand new code will become existing code that needs to be maintained.

If you’re aware of the three warning signs discussed in this article, then you’re already ahead of the game. For even more information, including strategies for refactoring, tips for writing better CSS, and ideas for how to test your CSS, check out CSS Refactoring.