One of the many beauties of working with Sass is how easy it is to get organized. In the past, importing different CSS files wasn’t good practice and in fact made for more HTTP requests. With Sass, you can have many different partials which allow you to isolate styles in a logical way.
What is a partial? The Sass Documentation explains it pretty well:
If you have a SCSS or Sass file that you want to import but don’t want to compile to a CSS file, you can add an underscore to the beginning of the filename. This will tell Sass not to compile it to a normal CSS file.
Organizing Sass files in this way, then allows you to create a sort of “table of contents” with a global.scss. I create about 13 partials; one for forms, icons, type, mixins, images, etc. Each partial has only the styles that belong, making styles easily findable.
stylesheets/
_bits.scss
_forms.scss
_icons.scss
_images.scss
_mixins.scss
_type.scssOnce you’ve created your files, you then import them into your master stylesheet. I like putting comments to remember what each partial is doing.
/*
VARIABLES
---------------
Setting up variables. Bringing in Colors and Spacing.
--------------- */
@import "bits";
/*
BASE STYLES
---------------
Setting up the base. Bringing in Type, Images, Forms, and Icons.
--------------- */
@import "type";
@import "images";
@import "forms";
@import "icons";Organizing yourself like this can be difficult to adopt at first, but I can’t tell you how much time I’ve saved. On large projects, knowing where to look is half the battle. Gone are the days of 3000 line stylesheets. Instead we can work in small, specific, and more importantly, manageable files.
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
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.
@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.
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.
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.
(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….
Is that the sourcemap files will always compiled when sass files are prefixed with the underscore ?
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”;
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.
I would love to see an example of a page’s main.css that demonstrates this modularized approach to styles.
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.
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.
Would you specify media queries in all of those? How would you implement responsive design with the separation of files?
@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.
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.
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.