DEV Community

Annie Liao
Annie Liao

Posted on

8 SCSS Best Practices to Keep in Mind

#css #productivity #design

This past week I had an opportunity to browse through a company's coding guideline, some of which I found very useful not only in collaborative settings but also in developing personal projects.

Here are eight of SCSS best practices from the guideline that made me rethink the way I structure my CSS code:

Note: The following tips are geared toward SCSS, so some might not apply to pure CSS. Big thanks to @yzoja and @8detect for the great reminder!

1. Mobile First

When it comes to responsive design, it's common to prioritize the desktop version, which can make customizing for mobile a painful process. Instead, we should design to expand, not cram things to fit mobile.

Don't:

.bad {
  // Desktop code

  @media (max-width: 768px) {
    // Mobile code
  }
}
Enter fullscreen mode Exit fullscreen mode

Do:

.good {
  // Mobile code

  @media (min-width: 768px) {
    // Desktop code
  }
}
Enter fullscreen mode Exit fullscreen mode

2. Set Variables

Defining CSS variables and mixins should be part of the initial setup, which can make the project much more maintainable.

According to the guideline, here are some common properties that will benefit from variables:

  • border-radius
  • color
  • font-family
  • font-weight
  • margin (gutters, grid gutters)
  • transition (duration, easing) – consider a mixin

3. Avoid #id and !important

Both !important and #ids are considered overly specific and can mess with the order of CSS rendering especially when developing collaboratively.

Don't:

#bad {
  #worse {
     background-color: #000;
  }
}
Enter fullscreen mode Exit fullscreen mode

Do:

.good {
  .better {
     background-color: rgb(0, 0, 0);
  }
}
Enter fullscreen mode Exit fullscreen mode

4. Avoid Magic Numbers

Try not to set arbitrary numbers because they "just work"; other developers might not understand why the property has to be set in such particular numbers. Instead, create relative values whenever possible.

If you're interested, CSS Tricks have a clear explainer of why Magic Numbers are bad.

Don't:

.bad {
  left: 20px;
}
Enter fullscreen mode Exit fullscreen mode

Do:

.good {
  // 20px because of font height
  left: ($GUTTER - 20px - ($NAV_HEIGHT / 2));
}
Enter fullscreen mode Exit fullscreen mode

5. Descriptive Naming

It's easy to define CSS selectors according to the looks. It's better to describe the hierarchy.

Don't:

.huge-font {
  font-family: 'Impact', sans-serif;
}

.blue {
  color: $COLOR_BLUE;
}
Enter fullscreen mode Exit fullscreen mode

Do:

.brand__title {
  font-family: 'Impact', serif;
}

.u-highlight {
  color: $COLOR_BLUE;
}
Enter fullscreen mode Exit fullscreen mode

6. Zero Values and Units

This one might be up to personal choice or specific project style guide, but consistency is key. The rule below asks that you specify units on zero-duration times, but not on zero-length values. Also, add a leading zero for decimal places, but don't go crazy (more than three) on decimal places.

Don't:

.not-so-good {
  animation-delay: 0;
  margin: 0px;
  opacity: .4567;
}
Enter fullscreen mode Exit fullscreen mode

Do:

.better {
  animation-delay: 0s;
  margin: 0;
  opacity: 0.4;
}
Enter fullscreen mode Exit fullscreen mode

7. Inline Commenting

The best practice here is to comment on top of the property you're describing. Also, use inline commenting (//) instead of block-level comments (/* */), which is harder to uncomment.

Don't:

.bad {
  background-color: red; // Not commenting on top of property
  /* padding-top: 30px;
  width: 100% */
}
Enter fullscreen mode Exit fullscreen mode

Do:

.good {
  // Commenting on top of property
  background-color: red;
  // padding-top: 30px;
  // width: 100%;
}
Enter fullscreen mode Exit fullscreen mode

8. Nesting Media Queries

In order to easily locate media queries, it is recommended that you keep the media queries at the root of the declaration instead of nesting them inside each selector.

Don't:

.bad {

  &__area {
    // Code

    @media (min-width: 568px) {
      // Code
    }
  }

  &__section {
    // Code

    @media (min-width: 568px) {
      // Code
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Do:

.good {

  &__area {
    // Code
  }

  &__section {
    // Code
  }

  @media (min-width: 568px) {
    &__area {
      // Code
    }

    &__section {
      // Code
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

These are by no means an exhaustive list of best coding practices, but they certainly play a vital role in designing readable, scalable web apps. Is there any CSS guideline that you follow as your north star? Let me know in the comments!

Latest comments (52)

Collapse
 
smartdev322 profile image
smartdev322 •

Awesome!

Collapse
 
surajkhupse profile image
Suraj Khupse •

Great tips for beginers

Collapse
 
ads-bne profile image
ADS-BNE • • Edited

Thanks, this is an excellent post!

Heres a few additional things that helped me:

1Avoid naming colour variables after the colour. Go for $primary, #secondary, $light, $dark, etc. Eg:

$primary: #0000ffl
// Instead of 
$blue: #0000ff;
Enter fullscreen mode Exit fullscreen mode

You never know when a company will change it's colour scheme, and you can re-use the same colour.scss file accross multiple projects.

Another handy thing I use is creating new variables at the top of sections .scss files. For example, if I have a footer.scss file, at the top I might have:

$footerBackgroundColor: $secondary;
$footerTextColor: $pimary;

.footer {
  background-color: $footerBackgroundColor;
  color: $footerTextColor;

 a {
   color: $footerTextColor;
  }
}
Enter fullscreen mode Exit fullscreen mode

That way I don't accidentally miss changing colours.

Collapse
 
gracesnow profile image
Grace Snow •

This is a really good summary. The only one I'm regularly guilty of is nesting the media-queries. I always do it and then regret it later!!

Collapse
 
fly profile image
joon •

I find number 8 to be a struggle all the time, but I think it comes down to how many nested classes your mind has the capacity to remember. Personally anything more than 2 nested classes results in me scrolling longer than actually reading and apprehending the code.
The rest - totally agree. Very informative post!

Collapse
 
jafuentest profile image
Juan A. Fuentest Torcat •

What's wrong with background-color: #000; ??

Collapse
 
liaowow profile image
Annie Liao •

That one was not about colors, but using .class vs. #id, which is debatable, as you might notice from the comments. I should've kept the color code consistent, sorry for the confusion. That said, the guideline prefers RGB values, and here's their full explainer on colors: github.com/we-make-websites/wmw-co...

Collapse
 
jafuentest profile image
Juan A. Fuentest Torcat •

It makes sense, I never thought about the readability of rgb vs hex. Probably cause I've been using hex for years xD

Collapse
 
horaceshmorace profile image
Horace Nelson •

Pretty good article, but you’re mistaken about #ids. Using #ids is invariably dramatically more performant than using .classes when the downstream CSS is processed in the browser. Whatever you might subjectively gain in style in SCSS (I’d argue against that, too) will not come even close to matching what you’ll lose objectively in CSS processing/rendering time.

Collapse
 
dbkup profile image
Boki •

Some nice tips here, most of them I agree with based on my experience.

  1. Performance is an lesser known benefit when using the mobile first approach. The browser can just ignore the media queries which results in faster css processing as well as less processing.

  2. Not sure if, with hierarchy, you meant to say html structure. I believe it's important to note for someone who may think this. I believe strongly we should not bind css classes to html hierarchy. Meaning if you do .teaser-content-title and then have to add another element between content and title, your css is inconsistent. I'm a proponent of using BEM and Atomic design which make the process of thinking about your classes much clearer.

  3. Nesting with &__section is quite troublesome with regards to reading, searching, and refactoring the code. Some find it useful and like the brevity, but autocompletion in most IDEs solves this non-issue.

Collapse
 
bitdweller profile image
Pedro Pimenta •

All good tips, but I have a different preference regarding the nested media queries definitions: I actually prefer nesting them separately inside each declaration. I find it easier to check what's happening and don't need to scroll much to find the changes for each media query.

Also, for better performance, it is a good practice to merge all media queries on processing the SCSS files, using something like github.com/SassNinja/postcss-combi..., for example

Collapse
 
netanelravid profile image
Netanel Ravid •

Great article! Thanks!

View full discussion (52 comments)