Moving to SASS from CSS

Why SASS over LESS?

So initially I was tempted to just go with LESS as this seems to have more 'out of the box' support with Visual Studio including support for the .less file types and the default ASP.NET MVC solution templates being set up to support LESS out of the box (including LESS 'compiling' bundling and minification). I'm sure those reasons alone are why many ASP.NET developers go straight from regular CSS to LESS. After mentioning this to a friend he mentioned that SASS was the best thing ever and is what I should definitely use! There are plenty of comparisons of the two technologies and there seems to be a lot of arguments for using SASS, so that is what I decided on.

If you opt to use SASS, then you will want to look at using the free Mindscape Web Workbench. This handy Visual Studio plugin compiles your SASS as you save which is a really nice approach as you don't need to add any runtime compilers/preprocessors into your solution. Web Workbench automatically generates the output css files which you will refernce from your project.

My re-factoring approach for CSS to SASS

After some quick googling, I found this guide on how to structure SASS projects - slightly overkill for my little blog site, but a good start anyway.

Existing CSS structure

My existing CSS structure consisted of the following files whose purpose should be pretty self-explanatory:

• reset.css
• colors.css
• fonts.css
• layout.css
• prettify.css

prettify.css is for the google JavaScript library for formatting code samples - I included the CSS file in my solution, so I could bundle it along with my other CSS files to minimise the number of requests made by the browser, a suggestion from Google Analytics. Notice that I had separated my CSS into colours, fonts and layout - I opted for this a while ago after reading some dodgy 'best practices' article I found (maybe on slideshare?), but in my opinion this is not a great approach so don't copy that! You end up declaring the same selectors in the different files so it can actually make maintenance harder than using one CSS file.

Intermediate SASS structure

So my (intermediate at least) SASS structure looks like this (all empty files to begin with)

• Modules
  • _colors.scss
  • _fonts.scss
  • _layout.scss
• blog.scss

SCSS files starting with an underscore are to be referenced by other SCSS files and do not get translated into a CSS file. blog.scss gets parsed along with _colors.scss, _fonts.scss and _layout.scss to generate blog.css. The start of blog.scss looks like this:

@import 'Modules/_colors.scss';
@import 'Modules/_fonts.scss';
@import 'Modules/_layout.scss';

Since this was an exercise in re-factoring, I wanted to make as few changes as possible while moving from CSS to SCSS. So my approach for colors.css, fonts.css and layout.css was as follows:

1. Copy contents of css file into equivalent scss file (e.g. fonts.css content pasted into _fonts.scss).
2. Copy contents of css file (e.g. fonts.css) into blog.scss
3. For each css selector with a font type declaration in _fonts.scss refactor into a scss variable (see below)
4. Copy the newly created variable name and replace the equivalent font declaration of the equivalent selector in blog.scss

Re-factoring a CSS selector into a SCSS variable

p, ol, ul, li, span, h1, h2, h3, h4, h5, h6, dl, lh, dt, dd {
    font-family: Georgia, serif;
}

$default-font: Georgia, serif;

p, ol, ul, li, span, h1, h2, h3, h4, h5, h6, dl, lh, dt, dd {
    font-family: $default-font;
}

This may seem a little cumbersome but it follows the approach of refactoring, which is to re-structure code without changing its behaviour, so I could validate that my newly created SCSS files would work the same as the old CSS.

So this concludes my approach for re-factoring CSS into functional (but not optimal) SCSS. Optimising will follow in another blog post.