Lesson Weekend

In addition to supporting variables, Sass syntax also allows us to nest one (or multiple) styles within another style! This lesson will explore how to nest Sass styles, the benefits it offers, and several examples of how this tactic can help keep our sites' styles DRY.

Nesting

Nesting simply refers to the act of housing code within other blocks of code. For instance, consider the following basic HTML:

<!DOCTYPE html>
<html>
  <head>
    <title>Sample Web Page!</title>
  </head>
  <body>
    <div class="container">
      <h1>Heading</h1>
      <p>Content</p>
    </div>
  </body>
</html>

In the example above, <title> tags are nested within the <head> element, which in turn is nested within <html> tags. Similarly, our <div> is nested in <body>, and the <h1> and <p> elements are nested within the <div>.

Nesting is usually denoted by indentation. We've used nesting in everything from HTML to JavaScript and jQuery in previous courses. However, have you noticed that we don't nest in CSS? Even though CSS does contain indentation, as seen here...

.sample-class {
  font-size: 16px;
  color: red;
}

...This indentation is just the recommended style for CSS code. While style declarations are indented within a their style rules, we're not actually putting an entire rule into another rule, so the code above is not truly nesting. We don't and cannot nest an entire CSS rule within another CSS rule in the same manner we can in HTML...

...But we can in Sass!

Nesting in Sass

Check it out! Here's an example of nested Sass styles, as seen in the Sass documentation:

nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li {
    display: inline-block;
  }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

The code begins with a nav selector, and opens up a pair of curly brackets like any standard CSS rule. But within those brackets are three other entire rules! Each with their own individual selectors and declarations. These are nested styles, also known as descendant selectors.

Once compiled, the Sass styles above will turn into the following CSS in our output file:

nav ul {
  margin: 0;
  padding: 0;
  list-style: none;
}

nav li {
  display: inline-block;
}

nav a {
  display: block;
  padding: 6px 12px;
  text-decoration: none;
}

Benefits of Nesting

But why would we nest our styles like this? There's two big benefits: Organization and readability.

As seen in the nested Sass above, we can organize all styles relating to a specific area of the layout (like nav, in the example Sass above). We don't have to precede each selector with nav, because they're already nested within a nav. This makes the styles easier to skim, less redundant, and modularly organized.

The nested nature of the Sass styles also more closely mimics the manner in which their corresponding HTML elements are nested within one another, making it easier to line up which styles corresponds to which HTML elements. This can make deciphering, debugging, and collaborating upon styles easier.

Drawbacks of Nesting

There are some drawbacks to nesting though, too. Primarily, that it can actually result in styles that are too specific, which can lead to problems. As explained in Steven Bradley's article The Pros and Cons of Nesting Your Sass Code:

There’s nothing specifically wrong with nesting, but you can run into problems if you nest your code too many levels deep. For example say you have the following HTML and you want to style the link.

  <main>  
    <div class="one">  
      <p class="two">Some text  
        <a href=""></a>  
      </p>  
    </div>  
  </main>

You probably know that a selector like main .one .two is overly specific. The link you’d style in the selector is tightly coupled to a specific HTML structure, which is generally something to avoid.

However, if you nest your Sass you could be fooled into thinking your selector isn’t specific at all

  main {  
   .one {  
     .two {  
       a {
         color: red
       }  
     }
   }  
  }

The Sass makes it appear as though you just styled a simple link, but once the Sass is compiled you end up with the same overly specific selector we saw without the nested Sass.

One problem with overly specific selectors is you have to write even more specific selectors to override them for that one case where you want an element to look different or your styles fall apart when you decide that an element inside one area of your design should be moved to another area of your design.

However, this issue is easily avoided by simply following best practices, as Bradley continues to explain:

While I agree that nesting too many levels deep should be avoided, I don’t think that makes nesting a bad thing or something to be avoided. True, it’s easy to get carried away and end up with some very specific selectors, but it’s just as easy to get carried away writing very specific selectors in CSS.

...nested Sass doesn’t create bad code. Bad coders do. Yes it’s easy to nest too many levels deep. The solution is easy. Don’t do it. There’s nothing forcing you to have deeply nested Sass code and once you understand you shouldn’t, it’s not that hard to avoid.

Work on organizing your styles in a nested fashion in your own projects. But, as a rule of thumb, avoid nesting more than one or two layers deep without thoroughly considering ramifications.

Required Video: Nesting Styles by NetNinja

Continuing with NetNinja's Sass series, watch the following ~6 minute video demonstrating more nested styles in action:

Sass Namespaces

There's also another handy nesting trick Sass offers to further DRY up our styles. You know how some CSS properties are all preceded with the same term? Like how font-family, font-size, and font-weight are all preceded by the term font and a hyphen?

This is because they're all in the same namespace. Specifically, the font namespace. A namespace is a container to organize logically-similar items. In this case, the creators of CSS placed font-family, font-size, and font-weight in the same namespace to organize them within the CSS language, because they handle logically-similar styles. They all handle different manners of styling font.

But despite being namespace-siblings, plain CSS still requires we preface each with the term font in our rules. But Sass doesn't! Check out what the Sass documentation on Nested Properties tells us:

In CSS, if you want to set a bunch of properties in the same namespace, you have to type it out each time. Sass provides a shortcut for this: just write the namespace once, then nest each of the sub-properties within it. For example:

  .funky {
    font: {
      family: fantasy;
      size: 30em;
      weight: bold;
    }
  }

is compiled to:

  .funky {
    font-family: fantasy;
    font-size: 30em;
    font-weight: bold; }

The property namespace itself can also have a value. For example:

  .funky {
    font: 20px/24px fantasy {
      weight: bold;
    }
  }

is compiled to:

  .funky {
    font: 20px/24px fantasy;
    font-weight: bold;
  }

Check out this comprehensive list of all CSS properties. Notice how many properties begin with the same prefix? These are all namespace siblings, and can be nested as seen above!

Lesson 22 of 36
Last updated more than 3 months ago.