Tips for Writing Modular CSS
No matter how much you love CSS, no one enjoys writing or maintaining style sheets that are 2000+ lines of awesomeness. The smart way to approach your CSS is from a modular stand point. Properly organizing your CSS, breaking it into smaller chunks, and naming classes in a generic way are a few places to start. Let’s review some of my top tips for writing modular CSS
There’s a few systems out there for organizing your CSS but the best one I’ve found is SMACCS (Scalable and Modular Architecture for CSS). The great thing about this system is that it’s easy to learn. You can pick it up in a few hours and start yourself down the path of modular CSS. Basically you need to divide your stylesheet into 5 sections:
All native HTML selectors, element selectors, descendant/child selectors, and pseudo-classes. For example: body, form, a.
Styles specific to the layout of your website or template. Stuff like .header, .nav, .box.
Reusable classes or components. A good example here would be the components from a CSS framework like Bootstrap.
Here you add any state change CSS like alerts or form validation styles.
This section is optional but if you have any theme specific CSS that doesn’t fit into any of the above sections, it should go here.
If you’re going to be coding modular CSS it’s critical that you become comfortable with a CSS Pre-processor. There are lots to choose from but my favourite is Less. In your variables Less file you should create a collection of global properties that are used throughout your CSS. To really keep it modular, it’s a good idea to only include global properties in this Less file like: colors, backgrounds, text, links, margin, and padding to name a few. My boilerplate variables file looks like this:
Regardless if you are working with a CSS framework or not, it’s a good idea to break components into their own Less files. Some examples would include things like tables, forms, and buttons. Within those Less files you should create component specific variables that use values set in your global Less file. Some people prefer to have all their variables in one file. My preference is to include the component specific ones with the component Less code. That way all the variables and regular CSS are together and the module is more complete.
One Theme to Rule Them All
You should create a single Less theme to act as your master theme. Within it import all of your component Less files I mentioned in the previous section. The master theme should also be organized using SMACSS. This keeps the main theme shorter and more manageable. Check out this Github Gist to see a theme boilerplate you can use as a starting place.
Keep Class Names Generic
You want to try and keep your class names as generic as possible so that they can be reused for multiple components. Create a .box don’t create a .red-box. Here’s some examples
Layering on generic classes is the better way to go in comparison to more specific class names. This will allow you to reuse more of your code and keep it DRY (Don’t Repeat Yourself).
Avoid Long Selector Strings
Another thing you want to avoid is long strings of selectors that are very specific. For one this makes the code harder to read/troubleshoot for other developers. This is also a really non-modular way to do something. Like I explained above, you want to layer on classes, not create long specific strings of selectors.
.wrapper-widget .widget-one .widget-one-header h1.widget-header
Avoid Using IDs
Don’t use IDs for styling. They mess with specificity and just add confusion when you’re troubleshooting a problem. In web app development, IDs should be reserved for hooking in functionality. It creates a nice separation between the view and function of an app. It also helps to keep your CSS clean by not mixing classes with IDs.
Don’t Use !important
C’mon man, this shouldn’t even need to be mentioned but I will anyhow. Don’t use !important !?! It’s just lazy developing :)
Hopefully this has given you some of the basics to start writing modular CSS. There is definitely more that can be discussed on the subject so feel free to leave a comment below.
Originally published at mattlambert.ca on May 25, 2015.