Don’t deeply nest your SASS or LESS 5/21/13

By Chris Johnson

CSS preprocessors like SASS and LESS are fantastic tools for helping you write CSS more efficiently. However, one bad thing they enable (and often encourage) is writing deeply nested rules like this:

header { width: 90%;
  nav { background: #000;
    ul { list-style: none;
      li { float: left;
        a { color: #fff; } 
      }
    }
  }
}

I’ve written code just like what you see above, and I’ve come to regret it every time. Deeply nested code is tough to read and it tightly ties your CSS styles to the HTML markup of the page. Ultimately, that means your styles will be hard to maintain and nearly impossible to reuse across your site. For instance, if we move the nav element out of the header and into the footer, the nav will be completely unstyled until we change the CSS.

This is how I would rewrite the above code:

.header { width: 90%; }

.nav { background: #000; }

.nav-list { list-style: none; 
  li { float: left; 
    a { color: #fff; }
  } 
}

Instead of relying on tag selectors like header and nav1, I use classes that could be used anywhere on a page2. The .nav selector isn’t nested inside the header tag, so I could move the nav element to another part of the page and these styles would still work.

I still use nesting inside the .nav-list, but only because I’m relatively certain the HTML markup inside the list won’t change. Even if it does change from being a ul to some other type of tag, the CSS would need to be rewritten since the styles are specifically changing the default styles of a ul.

  1. Targeting generic tag names like header, nav, and footer is almost never a good idea since they could be used in contexts you haven’t anticipated. For instance, a blog page could have an overall header and footer, and then a header and footer for each post. 

  2. IDs are fine as selectors if you’re certain you won’t need to reuse the styles.