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.
{code type=css}
/* Background Colors */
$background:
$header-background:
$content-background:
/* Colors */
$heading-color:
$link-color:
/* Typography */
$sans-serif:
$serif:
{/code}
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:
{code type=css}
$background:
$background-header:
$background-content:
{/code}
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.
- color
- typography
- grid/layout
- reset
- base
- forms
- tables
- navigation
- components
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
Summary
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.
You are very likely to somehow excuse for this posting. You don’t have to, i am very happy i have found this, as i am a bloody novice and struggling with very similiar thoughts: “How the hell do i do this the best possible way?!”
Thank you, helped me a lot.
Thanks Jan. I’m glad I’m not the only one thinking these thoughts and also glad I could help out.
The problem with stuff like “putting all colors into one color file” is that those files tend to get really big and messy. On the other side dedicated color in module specific files can lead to incoherent color-definitons. This is why I like to keep something like a global “styleguide color definitions” file which contains global colors. If I want a super special color for a certain module I just create a new variable in the module-specific file. (Sorry I’m not native english 😉 ) Take a look at this example architecture. https://gist.github.com/saviomuc/8cb7a45db2803d9cdaec . Of course this is very generic. But I think you get the idea. Regarding stuff like typo I put it into a typo.scss. Check this gist: https://gist.github.com/saviomuc/5555984 If you want to know more I’m more than happy to answer your questions.
This is great! Thank you for sharing your ideas.
I try to extract the best practices from every snippet i find.
Thanks Savio. What you do is kind of what I was thinking about doing. I like the way you’ve structured everything.
I’m curious why you think all colors in one color file gets big and messy. I don’t mean I would place every line of css where color is set in a separate file. That would definitely get messy. I’m thinking more that the color file would essentially define all the variables I’d use elsewhere. It might end up being a file where I could quickly change the entire color scheme of the site with a few quick changes.
Thanks for the links. I’ll definitely look more at how you set everything up.
I personally use a mixture of both. I define actual colours and shades (red, blue, green, purple, darkblue etc), then I use those colours (in the same definition file) to set variables like $header-title, $header-background etc. Often using slight variances like $header-border: darken($header-background, 20%);
Each to their own really!
That’s interesting. So you set up variables for the colors and then use those variables for things like $header, etc. Is that right? Or am I misunderstand the set up?
Thats a nice progression Savio.
This is going to be long. I hope there will be no formatting issues 😛
The reason behind this is because I’m developing mainly for big sites.
Normally you would expect that there is only one big brand guideline with fixed color definitions.
1. In an ideal world you’d have all the colors in one file with variable names like “brand-main, brand-secondary, brand-blue, brand-green”. Check the naming again. This is very generic and not bound to any context (except the brand) at all, still semantic in the way it describes its purpose (“name the brand colors”).
2. There is a big chance that these colors will never change, because they cost marketing and product development a lot. Changing one color means changing the color everywhere. Think print.
3. But there is a big chance that there will be additional colors because it’s cheaper to extend an existing color scheme than changing it.
4. According to that sales, marketing, hr and pr are going to say stuff like “Hey, I understand that we can’t change brand colors, but I really need glossy neon buttons and links on this landing page. UX labs and research showed that more people click when we go crazy with colors”. That’s the moment I tend to put “modul specific colors” into module specific styles.
But in the end this approach may fit companies with bad corporate design decisions but may be overkill for other companies. This is why I like to keep telling that this approach is more generic. Just don’t do it when you don’t need it.
Regarding the “I want to quickly change the color scheme”-Philosophy:
I really love the philosophy because this is one big argument I use when I talk to people about frontend architecture. In reality I never changed the entire color scheme of a page. 😀
And if you really wanted it could be very hard to manage. Let’s say you have two different links set to specific colors.
lnk-primary (interactive-blue) and lnk-secondary (cool-blue). Now brand wants you to switch colors. You will never want to switch the color definitions because then cool-blue wouldn’t be so cool anymore. Instead you directly change the variable within the module. I created a gist so you can see a code example https://gist.github.com/saviomuc/60f0f7f4bc96844ba6f7
Thanks Savio. Everything you said makes complete sense. I guess I was thinking more in terms of smaller sites or sites that are mine where I don’t have to deal with different company departments. I can see how you’d get requests for different colors and how it then makes sense to add them into module files as opposed to a single color file.
Now that you’ve pointed it out, I can see how your approach will make sense for something I’d like to do here. One of the things I’ve wanted to do is incorporate a bit of art direction. I don’t expect I’ll redesign different posts since it’s probably more work than what you get from it, but I was thinking I could do some simple things like experiment with different color schemes on different sections of the site.
I can see now where it might not make sense to have one universal color file in that case and perhaps do something closer to how you’re adding some colors into module files.
Thanks for the gist. I’ve starred all 3 links so I can find them easily again and look deeper into each. I appreciate the thoughts. As you can tell this is something I’m still trying to work out for myself and it’s good to hear different perspectives to help clarify a few things.
Hi Steven,
I can assure you are doing pretty good for someone who has just startet using preprocessors. I am also struggling with some parts but try hard to discuss and teach related concepts with my team. If I’d want to incorporate art direction to different post I’d just load new dedicated stylesheet or even add a style tag within header for this post which overwrites some default. The main benefit is:
– Easy to maintain because you only need to care about that additional css for this particular post
This css would be the _individual.scss in the sass layout section. Of course you can move the scss to another place (like subdirectory of post folder). Just don’t try to overengineer. Check out Trent Walton’s Page. I really like the way he manages art direction (and the simplicity of his page) http://trentwalton.com/2013/04/10/reorganization/
Why not keeping it simple? =)
Thanks Savio. Good to hear I’m doing ok at this. 🙂
Little by little I’m putting the things I’m talking about here into practice and little by little adjusting what I do. It helps me to think through some things and post them here in part to get the words down and in part to get feedback from people like yourself who help give me new things to think about and lead me into directions I hadn’t considered.
What you’re describing is what I was thinking for art directed posts. Guess I’m thinking along the right lines.
I like how Trent Walton handles art direction. He doesn’t completely change everything, but does make a few changes that are enough to give the post a different feel.
Hi Savio,
May i ask how you provide seperation of layout and theme in your former mentioned exemplary SASS structure (if you do it at all)?
I’m struggling with exactly this topic at the moment, and my approach was to create 2 subs, _layout/ and _theme/, and add _individual.scss to both of them.
But this seems a bit messy to me.
I never had a customer before who really needed a complete repaint and I think that’s a somewhat academic issue. But the issue with repaints lies not in structure but naming. Basically when I create my modules I name them:
.module
That’s the basic class with the most important definitions. Think of a white lego block.
then I apply an additional class
.module-e-blue (e = extend, but you could also use t for theme)
This paints the module blue.
If I’d want to apply new themes I’d just create new classes (which could be extended into other rules or just added to the class-attribute).
A blue module would look something like
This way you don’t have to care too much about colors. Just keep your alternate colors in the global color or module file and apply/extend them into according theme-classes.
I’ve noticed that myself. How you name classes goes a long way toward how modular and maintainable your code is.
module class=”module module-e-blue” . Markup got messed up
At this point I prefer defining a placeholder in scss, like %module {…}, and then .module just extends the %module, whereas .module-e-blue @exstends the %module and adds the color. And your html is tidy then and scss stays maintainable, right? 😉
I need to step up my SASS game. I haven’t really played around with @extends even though I know how powerful it can be.
Yeah, keep up, placeholders and @extend are the best advanced tools beside easy spriting!
I guess I need to. It’s amazing how far behind you can fall when you stop to do something else for a few minutes. 🙂
Recently, I started creating a page to kick off each project based on http://styletil.es … each section of the page maps to SASS variables, where are all grouped in sub-sections of a variables partial. Each section, like typography, also has a partial that is imported by a bootstrap file that compiles everything to vanilla CSS.
I am still wrapping my head around OOCSS, SMACSS and BEM and I want to keep the code intuitive for my future self or others, so I don’t want to create a complex programming like architecture for CSS! I am still finding the right balance between modularity and tradition.
The fact that we are even thinking about how to improve CSS is a step in the right direction! Anyway, it helps me to have a visual map that is than a mood board and less than a mockup to promote modularity, branding and emotion.
Interesting Brian. I’m heading in a similar direction, though I’ve building things based on something more of my own template. I still have to do a better job of mapping everything to SASS. Each project it gets a little further. Makes sense how each section gets a partial. Thanks for sharing. Hearing how everyone else does this is helping me figure out what I want to do.
With OOCSS, SMACSS, and BEM, I’ve just been taking little bits of each and incorporating them into my work. Nothing wholesale at the moment, but a little here and there.
I completely agree with you about all this being good. We may not be where we want to go yet, but at least we’re all thinking about how to improve our css.
I go about variable naming for colors a bit differently. I use the same approach that http://ethanschoonover.com/solarized does:
$base00: darkest of this color
$base0: lightest of this color
$base10: medum version of this color.
I end up with something like this:
http://cl.ly/image/020k3V01112c
It works well, because it allows you to understand the context of the color (light or dark), so if it’s changed in the future, it should be a similar value to the old one.
Thanks Vince. That’s an interesting approach. I like how it makes it easy to tell the value of each and doesn’t lock you in to naming the colors explicitly. You’ve just given me some good ideas.
I’ve generally been giving the variables names like $primary, $secondary, and $tertiary so I can easily distinguish which is appropriate for different parts of the design. It would be easy to incorporate the value as in $primary-darkest or $primary-10 or something similar.
I like to see the thinking around your SASS organisation I’m in the same boat trying to make better use of SASS vs just having nested selectors and some scattered variables. However I think your focus for organisation shouldn’t reflect quick client changes but your (and others) ability to read and maintain your code. I think that the way you have laid it out isn’t too bad for that though.
I haven’t quite settled on a naming scheme yet, though like I mentioned in the comment above I’ve generally gone with $primary, $secondary, etc. I try to stay away from naming things $blue or $red.
There shouldn’t be any issue keeping things maintainable and also being able to make quick changes for clients. A big idea of maintainability is to be able to make those changes after all. I hope I didn’t imply I was allowing the code to become unreadable or less maintained.
I am also a total newbie and was recently thrown into a big mobile project, here are a few things I learnt:
1) Use sass watch, when I learnt this it made my sass life 100 fold better. I also created a simple batch file to launch sass watch that I could run before starting dev on that day.
2) Modules are your friend, I created a module for rounded corners, flexing, etc and then just @included them in main sass files that needed them.
3) This is personal preference but I kept my variables in a single module but also used maths functions to adjust them if needed, e.g. $pixelDef * 2
4) //* comment */ Allows you to see comments easily in dev environment and have the bonus of comment not being included in generated css files.
I hope this helps.
Thanks Deon. I use CodeKit to run Sass and I think it does the equivalent of sass watch for me. It updates my css files and also refreshes the browser which is nice.
Thanks for the tips on the modules. I’m still trying to do better and take advantage of things like that. Still learning. I just did some quick research on them and see why you like them. The fit quite well with some of the things I’ve been talking about here and have been wanting to do. Now I just need to get myself to make better use of them. 🙂
Comments are nice. I like that I can add some notes to myself in the .scss file and not have them end up in the css.
Thanks again. I appreciate the help.