Organize that Sass!

by Tim Smith

16 Reader Comments

Back to the Post
  1. Check out SASS Globbing to import a whole directory of your partials without having to manage your root stylesheet every time you add a new one: https://github.com/chriseppstein/sass-globbing

    Copy & paste the code below to embed this comment.
  2. The code I write will often times end up in someone else’s hands, or I may inherit a project from someone else. Or more likely I have to jump into a project I haven’t touched in 7-8 months.

    I find this method difficult to manage stylesheets because the way in which the stylesheets are broken up is entirely arbitrary based on author’s preferences.

    For example – where would the line-height of a label element be? In forms or typography? It makes debugging and tracking down specific attributes more difficult. Having all my “screen” styles in one sass file makes is easier to search one document for either the label element I am looking for, and from there seeing what other styles are cascading to it.

    If I have to jump around multiple partials, or dig through various arbitrary overrides (bold was being overridden in forms.sass) then I am spending more time overall.

    I would argue that it’s better to use extends and mixins in a _base.sass file and then have the rest of your stylesheets be media-specific (screen, print, etc). Having one document (even if it’s 3000 lines) is easier to manage for me.

    Copy & paste the code below to embed this comment.
  3. @Jeremy – I hear what you are saying. It can be confusing. This is something I covered in my article entitles “Clean out your Sass Junk Drawer” (http://blackfalcon.roughdraft.io/4436524).

    In my article I go into depth about how file structures are one thing, but the real power is on the methodology of how you are building your styles. Following a SMACSS approach I pay special attention to the base styles and then everything beyond that is addressed at the module/component level.

    Like the label example you reference, I would say that if the line-height of the label is different from the normal line height of the site, then this would be applied to the label tag in the form.css.

    To take this a step further, if there are properties that are specific to a particular form module/component in the site, then all the styles would be maintained at that level.

    And I agree, there is a lot of power to be had in creating placeholder selectors at a modular/component level as well.

    Copy & paste the code below to embed this comment.
  4. I also like to add a couple extra bits to my SASS structure. I keep a /vendor directory in which I put SASS libraries I’ve found on Github, and then the unfortunate _shame.scss, which I use to isolate really hacky SASS that needs to be fixed before going to production.

    Copy & paste the code below to embed this comment.
  5. I couldn’t agree more with you Tim. Breaking down my big CSS files into little bits with the help of Sass was one of the first things I did after I’ve started using Sass. I often forget to tell people about ‘little’ things like that because I got used to it. Thanks for reminding me.

    Copy & paste the code below to embed this comment.
  6. (tiens je vais le faire en français, sorry guys)

    J’ai commencé à coder en Sass il n’y a pas longtemps. Et très vite j’ai utilisé des fichiers séparés. J’ai également tenté d’utiliser la méthode “Atomic Sass”.

    Assez rapidement aussi, je me suis retrouvé avec une masse de fichiers (15-20…) plutôt ingérables et, pareil que Jeremy AA, je n’arrivais plus à trouver d’instinct si line-height était dans _typography.scss ou un autre fichier.

    Je vais commencer deux gros projet bientôt, et il est clair que je limiterais mon nombre de fichiers à importer. Je crois qu’il faut s’en tenir à l’essentiel : base, reset, mixins, variables, types, layout, navigation, media et quelques autres. Le tout dans un seul répertoire.

    Aussi, la méthode Atomic me parait trop réfléchie et un peu inutile en fait….

    Copy & paste the code below to embed this comment.
  7. Is that the sourcemap files will always compiled when sass files are prefixed with the underscore ?

    Copy & paste the code below to embed this comment.
  8. i totally agree with you. i want to share a very small change that helped me to have an even more readable overview. i started to use only one import rule and than concat the partials. that way you have less clutter:

    @import
      “type”,
      “images”,
      “forms”,
      “icons”;

    Copy & paste the code below to embed this comment.
  9. Reusability is another reason for breaking down your Sass files into smaller parts, which can be used in different projects. It also allows for easier updates in shared Sass files – just recompile projects that use updated files.

    Copy & paste the code below to embed this comment.
  10. I would love to see an example of a page’s main.css that demonstrates this modularized approach to styles.

    Copy & paste the code below to embed this comment.
  11. I find it especcialy practical to create a variables.scss for the vars, then the globals.scss for the body styles and other globals, then follow the SMACSS pattern for layouts, modules, states etc. but extending the modules with the partials like the “buttons”, “forms” etc. 

    The most important part is the global typography.scss in which I set up the mixins and styles for every typographic element used on the site, but not the specifics like the “label”. 98% of the elements use those global type styles, the tiny bits are defined in module specific files.

    Copy & paste the code below to embed this comment.
  12. This is a good article outlining some solid core principles, I think you can potentially organise your SASS a lot better, depending on the kind of work you are doing.

    People have already mentioned SMACSS, I’m more a fan of MVCSS (http://mvcss.github.io/). They’re not too distant from each other though.

    The idea is you share your global styles across the sites and they should be reusable. You can then modify these with variables or extend this through SASS by creating project specific overrides to your global styles.  If you’re coming from a non-programming background it’s more difficult to get your head around this concept, and it might not necessarily be a feature of SASS that is for you.

    One part of MVCSS is the inbox, so if you are sharing a code base across several developers, pick up or put down projects frequently or need to hot fix something with some vanilla CSS you can write it in here. Code in this area can then allocated to the relevant part of the application as and when needed.

    Copy & paste the code below to embed this comment.
  13. Would you specify media queries in all of those? How would you implement responsive design with the separation of files?

    Copy & paste the code below to embed this comment.
  14. @Victor 1: Good question, I was thinking the same while reading the article. Still thinking I came out with a solution as follow, thought, as it’s on the spot, maybe is not complete.

    The idea is to create a series of file only related to screen’s resolution, for example: “_480to639.scss”, “_640to959.scss”, “960to1024.scss”, and so on. Each file will face the style of the elements within a specific resolution range (numbers are just for example thought). Once you have those files you can include them in the global.scss file inside a specific media query.

    Anyway that’s just an on the spot solution, will wait for Tim’s answer to that question.

    Copy & paste the code below to embed this comment.
  15. I like this type of organization, but I am personally splitting up my SASS by variables and mixins first, and then by module/area of the site. So header, nav, footer, etc.

    But I am also running into a problem with how to organize the media queries. Right now I’m using @Allessandro’s suggestion of a new file for each media query (ie. _over1024.scss, etc.) but it is definitely less than ideal since my desktop version almost completely rewrites my mobile styles.

    Copy & paste the code below to embed this comment.
  16. Hi @Brad-Bice, If I well understand your problem it’s just a matter of “cascade” definitions. Have the main file, let’s say “main.scss” and inside you’ll put your “underscore-starting” file modules. Something like this:

    main.scss
    |
    ——> _header.scss
    |
    ——-> _nav.scss
    |

    |
    /* here starts media queries for all the styles in the above files */
    |
    ——-> media query for screens up to X1
    |    |
    |    ——-> _upX1.scss
    |
    ——-> media query for screens from X1 to X2 (X1 < X2 of course)
    |    |
    |    ——-> _X1toX2.scss
    |

    Hope I’ve understand what’s your problem is and have replied coherently.

    Copy & paste the code below to embed this comment.