Structuring your CSS

Since this was published I have stumbled across Suit CSS by Nicolas Gallagher. Quite an awesome project that is right in line with what I propose in this post.

The internets is full of helpful advice on how to structure your CSS in a flexible yet rigid manner. I’ve been through many iterations of my own system and would like to share what I’m doing at the moment. I was a real heavy-duty BEM user for quite a while but eventually grew tired of the verbosity of the system. I’m also of fan of Jonathan Snook’s SMACSS and Nicole Sullivans OOCSS and my system is influenced by all three of them. Alright, let’s get down to it!

ID’s

Like most people that think about CSS I have opted to never use ID’s as styling selectors. The reason is simply that they are way to specific and makes it hard to design my stylesheets in a predictable manner.

Styling vs. functionality

I always differ between styling selectors and functional selectors. I’ll touch more on styling selectors in a bit, but you might wonder what functional selectors are? Well, my interpretation of the term is selectors that are used for other purposes than styling. It could be naming form elements (which I don’t really have a naming system for) but most of the time it is selectors that are used to run queries against the DOM in Javascript. I always prefix these selectors with ‘js-’ and use camelcased identifiers. Example: id="js-submitButton". This is simply to keep a separation of concerns, I wouldn’t want my styling to be forever attached to my functionality or vice versa.

Modules

This is a big one. I try to always arrange my styles in modules, and I have an explicit naming convention for these (inspired by BEM, as you’ll see). The idea with modulizing your CSS is that each class (no, never any ID’s) is responsible for styling one specific module – like your search box. The modules can then be broken down into components that are used by that very module. Modules always has name that are camelcased and has a first letter that is capitalized. Exampel: <div class="SearchBox">.

All subcomponents of this module are prefixed with the module name, followed by a hyphen and a component name, starting with a lowercase letter and in camelcase. Example: <input class="SearchBox-input">.

The last part of my module system is modifiers (again, BEM anyone?). They are applied to existing modules or components to alter their styling or behaviour slightly, enough to warrant a change but not enought to make it a component of its own. Modifiers are indicated by double hyphens at the end of a selector and named like subcomponents. Example: <input class="SearchBox-input--fullWidth">.

// CSS
.Button {
    //button styles here
}
    .Button-green {
        background-color:green;
    }

Regarding substyling of components there are two schools: using all classes is your markup or extending classes in your CSS. If I wanted to make a green version of my Button module using the “all classes” method, I could mark it up like:

// CSS
.Button {
    //button styles here
}
    .Button-green {
        background-color:green;
    }
// HTML
<button class="Button Button--green">

The “extending classes” method on the other hand would look like this:

//CSS
.Button, .Button--green {
    // Button styles here
}
    Button--green {
        background-color: green;
    }
// HTML
<button class=&quot;Button--green">

I don’t have a strict policy here but I tend to gravitate towards the latter, mostly because it makes for markup that is easier on the eyes and because I use SASS which makes it so darn easy to extend classes. Oh, I also treated you to a peek of another CSS rule of mine, indenting modules. I indent subcomponents one step under their parent modules and try to keep related selectors together.

The big benefits to be gained from this approach are:

  • Reusability. Once I’ve declared my Button-class I can use it anywhere and expect the same results. If a need for special buttons arise later in the project, maybe one with an icon in it, it’s a simple component/modifier away.
  • Specificity. Instead of .big-list > li > a I use .BigList-link and sleep like a baby knowing that I’ll never run into specificity issues further down the road. When I need to make it stand out I’ll just add .BigList-link--huge and get on with it. Sure, sometimes it’s just not realistic, or even good execution, to give every single element a selector of it’s own. But you get the idea!

 

Wrapper

Those are my three big rules! Naturally I have other little snippets of rules and regulation that I try to adhere to. But these are my goto guys.

  • RULE #1: Never use ID’s for styling.
  • RULE #2: Separate your styling from your functionality.
  • RULE #3: Keep a rigid but flexible naming system for your selectors.