- Nesting:
.anElement {
&_aBlock {
…
}
&_anotherBlock {
…
}
&_anotherBlockAgain {
&:hover {
…
}
}
}
- Limiting Nesting to Pseudo Elements:
.anElement {
…
}
.anElement_aBlock {
…
}
.anElement_anotherBlock {
…
}
.anElement_anotherBlockAgain {
&:hover {
…
}
}
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.:
…for one pretty simple reason.
With nested version, the string
foo__bar
doesn’t exist in your (S)CSS project, so running:…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.:
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).