browserWrangler

C-x M-c M-butterfly

I'll admit it... I didn't like the SCSS syntax when it was first added to Sass. I, like many other front-end devs using Sass at the time, thought it was super ugly and pushed too hard against one the main reasons I started using Sass — to make my stylesheets pretty.

Legibility is really important to me. I was of the opinion that SCSS would be as illegible as vanilla CSS.

A year or so ago, I was offered a job at Turing to come work with their front-end team. They intentionally do not use the Sass syntax, so my hand was forced to either learn SCSS or not accept the job. I decided that I shouldn't be so vehemently against a syntax without actually trying it out, so I took the job.

I am still with Turing... and SCSS rocks my pants. Here's what I've learned:

1. SCSS doesn't have to be ugly.
2. A lack of brackets actually makes some kinds of rule sets uglier than their bracketed counterparts.
3. Aligning CSS values makes a HUGE difference in code legibility.
4. Conditionally-overridden rule sets should be grouped together.
5. Sets of rules that are related can be grouped together for even more legibility.

Legible SCSS looks like this:

.popover {
  .content { background-color: #F4F3EF; }

  .inner {
    position: absolute;
    left:     -14px;
    width:    295px;
    padding:  0;

    .heading {
      @include linear-gradient($dark_gray_grad_top, $dark_gray_grad_bottom);
      @include border-radius(5px 5px 0px 0px);
      padding: 6px 15px 6px 30px;
      height:  36px;

      h3 {
        color:          white;
        font-weight:    normal;
        text-transform: uppercase;
        font-family:    'ProximaNova-Bold';
        font-size:      18px;
      }
    }

    .close-button {
      @include border-radius(11px);
      cursor:            pointer;
      background-image:  none;
      background-color:  #FFFFFF;
      border:            1px solid #BEBEBE;

      font-weight:       normal;
      font-size:         14px;
      font-family:       'ProximaNova-Regular';

      position:          absolute;
      right:             15px;
      top:               13px;
      width:             8px;
      height:            12px;
      line-height:       15px;
      padding:           4px 7px 4px 5px;

      // Conditional overrides
      // ==============================================================================================================

      &       { color: #FFFFFF; opacity: 0.7; }
      &:hover { color: #BEBEBE; opacity: 1.0; text-decoration: none; }

      // Modernizr fallbacks
      // ==============================================================================================================

      .boxshadow    & { @include box-shadow(#000 0 2px 5px); }
      .no-boxshadow & { border: 3px solid #000; }
    }
  }
}

Specifically, these are my strategies for writing sexy-looking SCSS... or SexyCSS........

>_>

<_<

... I’ll see myself out.

Property ordering is critical, and really has nothing to do with SCSS itself. Well-ordered properties can also apply to Sass, Less, Stylus, etc.

Property ordering from top to bottom:

1. @extend
2. @include
3. properties with string values
4. properties with integer values
5. child/nested selectors

@extend rules first, because they often come from styleguides. If you include these at the end of the rule set, you can potentially override using the default values, instead of the override values.

Similarly, @include mixins should also be at the top, for the same reason of accidental overriding using the wrong values.

Separating properties values based on whether they are string or integer values… why do this? Because it’s prettier to look at, to my eyes. Another thing I’ve recently started doing is grouping rule sets by similarities. For example, in the code above, my font settings and position/box settings in .close-button are separate from the rest of the rule set…. why do this? Again, because it looks prettier to me.

Aligning values up in columns is another huge legibility boon. For this, I use a Sublime Text plugin called vAlign... because there is absolute no way I want to do that by hand. If you are aligning your property values by hand, uh, stop doing that.

Ampersands are great. Aren’t they? I love me an ampersand. They are really useful in Sass/SCSS because they reference the entire selector chain up to that point which lets you do some pretty nifty things. Most people only ever use them to append pseudo classes on elements. However, there are some other amazing things you can do with them:

Use ampersands by themselves to group together rules that will be conditionally-overridden. For example, when you want things to behave differently when you hover. Use ampersands at the end of the selector, essentially re-scoping a rule set. For example, maybe you want to group together Modernizr fallback classes. Finally, one last important thing I try to avoid at all cost: DON’T NEST TOO DEEPLY. SCSS is much better at slapping you around for nesting too deeply. My general rule of thumb on nesting: If you’re nesting more than five levels, ask yourself if you need all of those levels. Sometimes the answer is yes, most of the time it’s no, and you can cut down some useless nesting.

So, there you have it. That’s how to organize your SCSS like a mo’ fraggin’ BAUS.