Maintainable Stylesheets with modular CSS and SASS

Although the syntax of CSS is not very difficult compared to other languages, writing maintainable CSS can certainly be a challenge. Stylesheets can quickly become an unordered pile of rules without any structure. Luckily with methods and tools like SMACSSOOCSS and SASS we can organize our code to be more intuitively and write CSS that is easier to maintain. They allow us to easily reuse code on different projects and make our code more flexible to accomodate changes.
For me personally using these techniques make me feel more confident about the product I craft and they generally make the entire process easier and much more fun. Because I feel they have made me a better developer I wanted to write a short post about how I use some features to organize my CSS. If you want to know all about how you can benefit from using SASS or write modular CSS I recommend visiting the links provided above.

Keep different matters into seperate files

SASS is a preprocessor which allows us to do al sorts of great things with CSS. SASS works alongside your regular stylesheet. You basically write all of your SASS code in a SASS-file (.scss). When this file is saved it is translated to regular CSS and a regular stylesheet will be updated with the changes. SASS has some features that are really great to bring some structure to your project. For example it allows us to spread our CSS out over multiple files with @import. Let’s use this to break up the main SASS-stylesheet (main.scss) into smaller more maintainable pieces. I like the main stylesheet to only contain the filenames that I want to include. This way it sort of acts like a table of contents and let’s us find code related to a particular subject fairly easy. The file main.scss could look like this:


/*
Theme Name: Mytheme
Author: Christian van Deursen
Author URI: http://webdesigner-webdeveloper.com
*/

@import "variables";
@import "reset";
@import "typography";
@import "grid";
@import "navigation";
@import "shadows_gradients";
@import "buttons";
@import "contactform";
@import "searchform";
@import "content";
@import "queries";
@import "print";
@import "ie";

All these imported files will be compiled into a single regular stylesheet in the end and thus will only cost a single HTTP-request. This is great for performance and still gives us the ability of having different matters into different files. When I return to a project months later and want to make some changes It’s usually quite easy to see which file contains the code that needs to be modified. Because every file contains less code it’s generally much easier to go through the stylerules and make modifications.

Use a modular approach to style content

When we style our content using a modular approach we can further enhance the organisation of our CSS. Take a look at this fragment of the content.scss stylesheet for example:


/* -- SERVICES -- */

.services {
  text-align: center;
}
.services h2 {
  margin-bottom: 0.3888888888888889em; /* 14px/36px */
}

.services-list {
  @include fontstack_sans;
  color: #fff;
}
.services-list li {
  background-color: #f2f2f2;
  list-style: none;
}
.services-list h3 {
  @include fontstack_sans;
  font-size: 1em; /* 18px */
  color: $color_offblack;
}
.services-list .iconfont {
  display: block;
  margin-bottom: 10px;
  font-size: 45px;
  color: $color_offblack;
}

/* -- CLIENTS -- */

.clients {
  text-align: center;
}

.clients-list {
  list-style: none;
}
.clients-list p {
  margin-bottom: 0;
}
.clients-list > li {
  border: 1px solid $color_border;
}

/* -- PERSONAL -- */

.personal {
  text-align: center;
}
.personal ul {
  list-style: none;
}
.personal ul > li {
  padding-top: 0.375em; /* 6px/16px */
  padding-bottom: 0.375em; /* 6px/16px */
}

In this example we see three different modules: ‘Services’, ‘Clients’ and ‘Personal’. The names of the classes are descriptive of the content we are styling and this makes it easier to understand what’s going on and gives us a feel for what belongs together. I like to put global stylerules at the top of the file. Anything specific to a certain type of content will go inside of a module. Modules are stand-alone components and when done right we can move a module in our markup without breaking it. Using a modular approach keeps our code flexible to future changes.

Compact and reusable code with variables and mixins

Variables and mixins are features of SASS. They allow us to easily reuse code in different parts of our project while we only need to modify it in one place. They also help to keep our code compact during development. A variable can hold a single value while a mixin can contain an entire codeblock with stylerules.


$color_blue: #009acd;


@mixin hide_text {
  font: 0/0 a;
  text-shadow: none;
  color: transparent;
}

In my projects I like to define all global variables and mixins in a seperate file called variables.scss. Mixins that are specific to a subject will be defined at the top of the file regarding that subject. For example a mixin in which a font-family is defined will be placed at the top of the file typography.scss. This way the code you need is always close at hand. Once defined we can include mixins and variables wherever we like in our CSS. In the following example we will hide the text of a link and add a background color by including the variable and mixin we defined earlier.


.nav .logo {
  @include hide_text;
  padding: 0;
  width: 263px;
  height: 63px;
  background: $color_blue url('img/logo_header.png') no-repeat 0 0;
}

If we want to hide the text of yet another link we just need to include that same mixin. Keep in mind that although this keeps our files smaller during development, the mixins will be replaced by regular CSS in the final compiled stylesheet. Another approach could be to define a dedicated class for hiding the text, for example ‘.hide-text’. This way we only need to include the mixin once when we define the class. This class will then be used multiple times in our markup.

Another great use for mixins are experimental CSS features. Before new features become part of the CSS specification they often contain vendor prefixes, like for example -webkit-box-shadow. When they eventually become part of the CSS specification these prefixes are no longer needed. If we want to remove them we will have to track down all occurences in our code. Had we used mixins then all we needed to do was to modify the definition.

These methods and tools are great to organize your CSS but they have a lot more to offer. They are really worth some of your attention so go check them out!

1 comment

  1. Ethan

    05-02-2014

    I like the way you explain SASS. Although I have played with SASS quite a while, I still learn a lot from it! Thank you!

Comments are closed.