Jun 9, 2015 0 Comments

Switch to Sass (SCSS)

I do lots and lots of css prototyping and have always written things in just plain old vanilla css. I didn’t really think I would benefit much from a css preprocessor, and at first, I really didn’t. I actually got really annoyed that I couldn’t get it to compile into what I would have written long-hand. Mostly this had to do with the cascade order of classes and where media queries ended up in the document, but I started to get the hang of it. I stuck with it for a few months and now I don’t think I will start a new project without it.

I went with SCSS

Mainly because I wanted to be able to write plain css mixed in with my preprocessor code. I know that Stylus and Sass favor white space rather than “unnecessary” { } : ; type characters, but I am so used to my text editor just throwing all those in for me that I don’t even need to think about them. Type a { and the other is already there at the end waiting for me. Even if I type the } at the end, the text editor combines them into one, preventing duplicates. White space can also be tricky to find accidental mistakes. Also I don’t want to have to worry about really long background-image urls that wrap lines.

LESS seemed less capable than SCSS, and I seem to naturally come across more examples and things written in SCSS/Sass anyway. I went with the popular choice – especially with the hope that some of the really successful features of SCSS will become native css in a future version (css 4?!). That would make me happy, since one of the (avoidable with build tasks) annoying things is the code I write with SCSS has to be compiled and occasionally double-checked to make sure the css is what I expect. Native browser SCSS would

Thinking in SCSS

I haven’t been using SCSS long enough to not feel the need to check the css output from the compiler, but that’s not what I mean about thinking in SCSS. The best example is the use of a placeholder class where you make a non-compiling class to extend into all sorts of things.

     width: 100%;  
     margin-bottom: 20px;   
     box-shadow: 0px 2px 4px rgba(0,0,0,.4);
     border: 1px solid $grey-l {radius: 3px;}
     background-color: #fff;


   .market-card {
     @extend %card-generic;
     max-width: 350px;
     margin-bottom: 30px;

   .any-other-card {
     @extend %card-generic;
     with: specific stuff;

This kind of feature makes me rethink how I am going to structure the markup and whether or not I will need any helper classes. Personally, I’d rather have fewer class selectors in the markup that need to go together always, and only use helpers when they are modifying the initial, singular class. I can now write less SCSS and get more optimized css output without the need for as many classes in the markup.

Shorter Files

Another favorite thing about SCSS or really any css preprocessor is I can split things into shorter files that are more manageable. Then I can have the preprocessor merge them all together into one file for deployment. The best part is I can focus on one area of the site, such as the various cards or the navigation without having to deal with lots of searching for keywords or accidentally putting something in a weird place in the cascade. It just helps with organization and fits the same concept as the rest of our component based framework for writing the rest of nibl. Also, since we have style sheets for promotional pages or our embedded widgets, I can just @import things like resets, mixins, and color libraries without having to rewrite and maintain them separately. It really helps keep things consistent and more maintainable across our product offerings.