I am a self-taught web develop, and it was merely a hobby. When I started working professional in the field, I was brought along very bad habbits that I picked up during my time in the wilderness. Some of those habbits are still with me today, including that perception that everything I work on is for my eyes only.
If you are the only developer of a project, it can be tempting to get lazy with how your write your code. With this attitude, it won’t take long for your code becomes a disorganized, unmanageable mess, but hey if it works who cares. Right? Well, the truth is it does matter a lot, which brings me to my true topic of this post, SMACSS.
SMACSS stands for Scalable and Modular Architecture for CSS and was developed by Jonathan Snook. SMACSS is a way of organizing your CSS code that makes it, as the name implies, more scalable and modular. I also find it easier to read, edit, and maintain.
However, if CSS is like mine, all jumble together in a single file, then SMACSS may take some time to get use to it. The first few times using the SMACSS methodology, I was confused on what declarations should go where and when should a split the same group of declarations. But after closely reading through Snook’s book found smacss.com here how I interpret you should use SMACSS:
There five categories: Base, Layout, Modules, States, and Themes.
Base is used for your single element selectors (e.g.
a). In fact this is ideal the only place that these types of selectors should be. This is also where you would put your reset or normalize CSS.
Layout is where you would put your basic page components. Do not confuse a module for a layout. If a component could potentially be repeated or exist on multiple location of page, it is a module not a layout. I usually only have three sections for layout,
Modules is where the bulk of your declarations will go. Navs, lists, tables, buttons, and forms are all modules. Ideally each module will exist in its own file. They should never use #id or element selectors only classes. Classes should be description of the module not of the location on the page, for by definition a module could be used anywhere on your page or site.
State is where you put your declarations that describes an elements state, for example
hidden. Now here is where things get a little confusing. If a state is directly related to a module and only a module it should be declared with the module. State is only used for global state declarations.
Theme is used for your theme specific declarations, if your site has more than one theme. According to Snook, unless you have develop a large website, you are unlikely to use this category.
If you get a chance to read the contents of smacss.com, and I recommend that you do, you will find Snook has something to say about the order of CSS properties. He explained that, “Some people organize alphabetically, others don’t organize at all, and others may use some other arbitrary system.” For a long time, I was in the second group. I just wrote my properties however they came about. Then around the time I started using SCSS, I switch over to alphabetical, because it was A way of organizing code. However, I was never happy with it. Alphabetical met that you spit up commonly grouped properties like
width. But Snook go on to show that organizes by grouping:
I immediately adopted this organization style but need a little more guidance, so I have come up with this more specific ordering:
This is all still a work in progress for me, but I hope it help bring order the chaos that is my CSS code.