Sass Best Practices – Nesting more than 3 levels deep

[martypowell]

I am currently building a web component using sass. I am have used sass for a bit, but am really trying to make an effort to make follow best practices and write solid css code.

I have setup a codepen for this. You can see in my sass comments that I am getting 6 levels deep, one thing Chris says not to do in his Sass Style Guide.

An especially problematic element is when you get into the unordered list. When I use lists I almost always require 3 levels of nesting.

I am trying to keep the css for this component very specific the so css can be included in any site without causing conflict and without any required overrides.

I would appreciate any tips/suggestions to help me with future sassing!

[Senff]

I also TRY not to get more than 3 levels deep, but sometimes I can’t avoid it without being overly unspecific. Indeed it happens most with unordered lists.

While I’m sure it’s possible to stick to the “no more than 3”-rule, in some cases I ignore it because my Sass file is so nicely structured, and to break out of that structure (just for the sake of not getting a 4-level nesting declaration) is a little too much for me.

You’ll see many 4-level (or higher) declarations everywhere in (post-Sass) CSS files, I’d say the 3-level rule is a guideline, not a law. I mean, is this really that bad?

footer .main a {color:#ff00ff;}
footer .main ul li a {color:#ff0000;}  /* oh no, 5 levels! */

I don’t think it’s that awful — the best I could do there is 4 levels deep anyway. All in all, trying to limit your nesting is probably just because it’s sometimes very easy/tempting to go way over the top.

body
    .wrapper {
        footer {
            .main {
                form.search {
                    fieldset {
                        input {

That’s what I did at first because it so nicely represented my site structure. Of course, this could probably have sufficed:

footer {
    input {

Anyway. I guess, don’t nest just because it looks nice in your Sass. Or something.

[TheDoc]

I definitely don’t like nesting more than three levels. Usually I reserve that 3rd level for pseudo elements and states (:before, :hover, etc).

I prefer using better classnames so I don’t need to nest that much.

In your Codepen example, why does .setting need to be nested? Does it require being under .easy-reader in order for its styles to apply?

If you’re worried about a class of .setting being used elsewhere and you don’t want to share those values you could use a more specific class like .easy-reader-setting.

[martypowell]

@TheDoc Thanks I think I either under thought this or overthought this . But I am going to take your advice with something like .easy-reader-setting. This really is a smaller component of my larger .easy-reader. Thanks for straightening me out.

[martypowell]

@Senff Thanks comments for well. Your are right, sometimes you need to break the guidelines for something like a unordered list, but lets ill try to avoid more than 3 levels if possible!

[Alan]

Why exactly is it bad to nest more than 3 levels deep? I find it incredibly useful and haven’t run in to any issues so far

[Paulie_D]

As I understand it, it’s because it can make your code hard to read from someone coming into it cold.

Also, it tends to make really complicated and overly specific selectors.

The SASS people tell you why

http://thesassway.com/beginner/the-inception-rule

[Alan]

That makes sense, I’m not sure I agree with the argument on the sassway that it majorly affects rendering performance though?

I only deep nest things from time to time and find it being overly specific really useful but equally useful is CSS’s cascading property.

[MattDiMu]

Long selectors won’t (significantly) affect your site’s performance in most cases, as browsers read the selectors from right to left (see: http://stackoverflow.com/questions/5797014/why-do-browsers-match-css-selectors-from-right-to-left/5813672#5813672) Only if you’d use general selectors all the time, there could be a measurable difference (e.g. div > * > * > * > * > * {…} – but who does that?)

IMO nesting selectors is no problem at all, if
– you’re the only one editing the styles OR
– you have consistent naming conventions (and a different developer therefore knows from the used class-names where and how to edit/extend the targeted component) OR
– you’re using sourcemaps (and when clicking on such an xl-sized selector, you get to the source scss/less-file)

One disadvantage remains, however: If you change the order of your html, you’ll probably need to adjust the scss/less-file as well – but usually that’s necessary anyway.

[Author]

Posts