Sass Nesting using &

sass-nesting.md

1. Nesting:

.anElement {

  &_aBlock {
    …
  }

  &_anotherBlock {
    …
  }

  &_anotherBlockAgain {

    &:hover {
      …
    }
  }
}

2. Limiting Nesting to Pseudo Elements:

.anElement {
  …
}

.anElement_aBlock {
  …
}

.anElement_anotherBlock {
  …
}

.anElement_anotherBlockAgain {

  &:hover {
    …
  }
}

@davidcmoulton agreed!

@adamj88 for some context, I'm working on a 10 year legacy project with 2000+ .scss partials, so searchability is a big plus for me.

@jaikdean "safer from typos and easier to refactor" yeah, that's a good point.

@thebrainroom

add inline comments (//) above the nested selector to show the output class

Never thought of this, solves the problem while keeping it DRY. A little susceptible to typos but at least they won't break the output.
Definitely going to try that.

I personally use Nesting. I like to think of anElement as a Class in the truest sense, and the contents as extensions of it.

I can absolutely see why, on a large project, this would be horribly unwieldy though, in which case, nesting pseudo only is the best solution.

As you asked for input I would simply point you to rule 1 here as it encapsulates (pun intended) the way I do/don't allow nesting in ECSS.io : http://ecss.io/chapter8.html

There are arguments on either side of the fence, depending on your use case (and one should always optimise for your use-case).

If you’re working in large or existing projects:

Prefer the longhand, e.g.:

.foo {}

  .foo__bar {}

    .foo__baz {}

…for one pretty simple reason.

With nested version, the string foo__bar doesn’t exist in your (S)CSS project, so running:

~/project/css/ $ git grep "foo__bar"

…will not yield any results. Classes are much harder to find because we’re splitting strings in half. The longhand means this doesn’t happen.

Also note the indenting; this gives me the same visual cues that nesting would (i.e. this goes inside this), with none of the drawbacks.

---

If you’re working in a project with a high rate of change (e.g. very iterative, prototypes, PoC):

Perhaps prefer the shorthand, e.g.:

.foo {

  &__bar {}

    &__baz {}

}

This just means that if names of things are likely to change frequently, the task is much simpler.

I tend to find this use-case is less common, so I normally tell people to stick with the longhand (and changing names in the former method is just a simple find/replace).

@thebrainroom

I add inline comments (//) above the nested selector to show the output class. This also helps you search a project for a whole class.

You mean like:

.foo {

  // .foo__bar
  &__bar {
  }

}

?

LONGHAND ALL THE THINGS!

Seriously - production source code should be a work of art, in structure, conventions, comments, accuracy.

Source code will inevitably need to be picked up and worked on by other people at some point (unless it's a private project that you actually want to be unfathomable).
Optimisations change over time as the browser landscape, protocols and server technology changes, accurate source code means that build systems can handle the changing requirements for optimisation.

.foo {
  &__bar {
  }
}

is fine if you're just throwing some styles together but in a large project, if I jump to: &__bar { ... on line 250 of a file, I need to scroll to the top to check which block I'm working in.

@csswizardry agreed, being able to easily find an element is the biggest win for me for a large project.

The ability to search a codebase for a class name is super important.

anElement will be repeated in your output a number of times anyways, so being DRY I'm not sure is really a concern here.

My vote - no nesting except pseudo selectors.