For most of the last year if I’ve written css, it’s been in a preprocessed SASS file, specifically a .scss file. Good for me, but I haven’t been taking advantage of most of what SASS has to offer. My .scss files are often little more than nested css. I’ve used variables here and there and included the occasional mixin, but my SASS use has been simplistic at best.
I’d like to change that and hope you don’t mind if I think out loud a little on how to start creating more modular and maintainable SASS projects.
An Example from a Recent Project
Recently I worked on a relatively simple project, a one page site with little content. I had it all designed and developed in an afternoon.
The end game consists of separate style sheets or SASS partials to reap the benefits of modular design.
While waiting on the client to have a look, I thought I’d play around a bit and refactor the css by setting up some variables for color and type in case the client came back wanting changes. As expected my client did want to experiment with color and type choices and having these values in variables made it easier to quickly try different possibilities.
My client, who had some design experience, would suggest a different color scheme and in moments it could be applied across the page. Want to see how different typefaces would look? No problem. Give me a second.
Variables are clearly useful and one of the great reasons to use a preprocessor. However, I don’t think I made the best choices in how I set up the variables. Here are some of the variable names and general organization I created.
/* Background Colors */
/* Colors */
/* Typography */
It’s not bad at first glance, but it really isn’t the best way to organize even these few variables. The main groupings are probably fine, but the variable names aren’t great. At the very least a naming scheme like:
would be easier to read. Variables like $serif and $sans-serif might be better as $display-type and $text-type;, which would be more reflective of their purpose instead of describing their values. My choice seems a little like naming a class red and risking you’ll want the color to later be green.
On the good side:
- I set up variables, which is a major step in the right direction
- I’m isolating color and type values and preparing both design layers for separate files down the road
On the bad side:
- The naming convention is poor. Using serif and sans-serif leads to a single css font-stack for each. Better would be to name them based on their function.
- The variable names are location dependent (header, content, link), which limits where they should be used.
Thoughts for Better SASS Organization
Variables are just the start.
The end game consists of separate style sheets or SASS partials to reap the benefits of modular design. The idea isn’t anything profound as it’s how many are already working with SASS and other preprocessors and it’s how frameworks and the like come into creation.
The obvious advantages are
- Ease of maintenance — A single set of styles would all be located in a single file
- Modular system for reuse — Style sheets could be refactored and collected in a library or framework
For example all color related css could be in one location for easy maintenance. All grid and layout related css in could be located in another file, and so on. Each file could be worked on independently so it could be applied to additional projects. Again, nothing others aren’t already doing.
The question I’m thinking through is what’s the best way to get there. I thought I’d start slow (unlike the larger forced changes I sometimes apply) to have fewer moving parts all at once. Before moving groups of selectors into separate files, I thought I’d start by organizing variables into logical groups and go from there.
Off the top of my head here are some possibilities for each of the groups.
Another thought is to organize around the SMACSS categories of base, layout, module, state, theme, though looking up at the list it pretty much includes the SMACSS categories and expands on them a bit.
Over the years I’ve tried to organize my css around similar design layers, however it hasn’t always gone well due to a certain amount of overlap. For example should the color of links in navigation be included under color or navigation? How about the choice of a typeface for the same navigational links?
Is it more likely the color scheme or type choices for the design will change or is it more likely the navigation will need change? The changes will be easier and quicker to make if everything that needs changing is located together.
Something tells me what I’m after calls for two systems of organization. One to keep all the navigation code together and one to make it easy to quickly change a color scheme across a design. Perhaps the first suggests how files should be organized and the latter suggests how to organize variables.
Now that I’ve thought out loud a bit, I suppose the next step is trying some of the above and seeing what happens and where issues come up.
Here are a few other posts with thoughts about this. As you can see I’m not offering anything revolutionary here. Just thinking out loud before putting these thoughts into greater practice.
- How to structure a Sass project
- GitHub CSS Styleguide
- Modular Front-End Development With Less
- The #1 Reason to Use SASS
- Sass: A Designer’s Perspective
I realize my thoughts here aren’t exactly earth shattering for most, but maybe these ideas will be new for some. It does help me to think through them and see them on the screen.
While I’m happy I’ve taken the step to writing css in SASS, I have a long way to go before I’m using it as well as I could. Thinking through how to best set up variables and variable names is a step for me toward modular .scss files. I hope you don’t mind listening in my thoughts.
I assume many of you are already beyond where I am with preprocessors and I’d be happy to hear how you’ve been setting up variables and files for projects. What do you find works well and where you’ve identified some trouble spots?
Download a free sample from my book, Design Fundamentals.