If, when working on code, we are forced to regularly use nested styles that are more than two or three levels deep, then there are some tricks we can use to reduce both the CSS specificity over time, and the need to use nesting more than two to three levels deep. Let's take a look at a few:
• Can you give yourself the class you need? Specificity can creep in if we're overriding an existing selector:
.section-header { /* normal styles */
}
body.about-page .section-header {
/* override with higher specificity */
}
To avoid specificity, can a class be emitted through the use of server-side code or functions, which we can use to style the element instead?
<header class="<%= header_class %>">
Which could output one class, or both, as desired:
</header>
.section-header { /* normal styles */
}
.about-section-header {
/* override with same specificity */
/* possibly extend the standard class */
}
• The order of your style sheets can play an important role here, even though you might use a single class to override styles:
<header class="section-header section-header-about">
...
</header>
Your existing class may be overriding your override; both selectors have the same specificity, so the last rule(s) to be applied will take precedence. The fix for this is simply to rework the order in which your style rules are applied, so that overriding classes can be applied later.
• Consider reducing the specificity of the element you're trying to style; can the element be replaced, or removed in its entirety? If, however, it's being used within JavaScript (or jQuery) code, then it is preferable to leave it as-is, and add a second class (or use an existing class already applied, if one exists).
• Where possible, aim to use as flat a structure as possible for your code; it is too easy to style an element such as this:
.module > h2 { }
In this example, we're styling all h2 elements that are direct children of the parent .module class. However, this will work until we need to assign a different style for the h2 element. If the markup looks similar to this example:
<div class="module">
<h2 class="unique">
Special Header </h2>
</div>
…it will be difficult to apply styles easily, due to CSS specificity creeping in:
.module > h2 {
/* normal styles */
}
.unique {
/* I'm going to lose this specificity battle */
}
.module .unique {
/* I'll work, but specificity creep! */
}
• To avoid this, using as flat a structure as possible is recommended—it will be worth the extra effort required to set it up:
<div class="module">
• Consider using an established pattern library, or atomic design (such as the one at http://patternlab.io/), to help guide you through how a site should be built—they are likely to be built using minimal CSS specificity, and with hopefully little need to override existing code.
• Be careful if you decide to use cascading when applying CSS styles—if we apply a base style to an element (or class) that is reused multiple times, this will cause issues. To avoid this, try to avoid using cascading if it isn't really needed; consider limiting it to 2-3 levels only, to reduce risk of odd or unexpected styles being applied.
• Sometimes code is outside of your control—in instances such as this, we have to work with it; we can either try using low specificity selectors where possible, or use the !important keyword to override the code. For now, we may have to leave comments in the code to explain why the selectors are set as such; in an ideal world, we would try to contact the authors to see if they can update or alter the code to remove these issues.
• As a last resort, if you must get into the realms of CSS specificity, then try to only apply a light touch, and not take the sledgehammer approach, such as using a selector ID or !important.
We can try applying a single class to an existing tag, but this may not feel right for some; an alternative is to use two classes:
.nav .override {
The key here, though, is to not use more than one additional class!
• Nesting styles can lead to writing overly specific selectors in our code—some developers discourage its use for this reason, even though nesting can help make our code visually easier to read and digest. Instead of using compound selectors, we can emulate a form of name-spacing by using the ampersand symbol: . somestyle-so { color: blue; } .somestyle-so-ever { color: green; }
• If your style is overriding a style that is already an override—stop: Why are you doing this? Overriding a class or selector element can be an efficient way of styling, but applying a second override will only cause confusion.
We've seen a number of ways of avoiding, or reducing CSS specificity issues that are inherent with nesting; the key message, though, is that we are not forced to have to nest our code, and that, to paraphrase the front-end architect Roy Tomeij—nested code doesn't create bad code; bad coders do!
You can see the original article by Roy Tomeij at http://www.
thesassway.com/editorial/sass-doesnt-create-bad-code-bad-coders-do
There is one method, though, that we've not touched on, and for good reason: it's a route many developers new to using processing will likely take for the first time.
Intrigued? It has something to do with using conversion tools, and more specifically, how we use them to convert from plain CSS to code suitable for compiling using PostCSS.