Mostly practical advices

Modular CSS

This isn’t a new idea but looking at people’s code it doesn’t seem to be a particularly widely used practice: modular CSS. That’s a poncy name for the very simple idea of grouping related styles into separate stylesheets. The same set of tasks turn up on project after project and a little careful thought can save hours of foundation work, allowing you to get on with the serious business of turning a flat design into a web page far more quickly.

The broad groups that I use are: typography, forms, layout, navigation and color. These aren’t set in stone and some projects require more or less categories.

Common components


Basic styles for HTML elements with font faces, sizes, weights and neutral colors. Bearing in mind that color is dealt with elsewhere you’ll probably only find you need to make minor adjustments to these between projects – a couple of ems here and there, bold to normal for a heading or two, that sort of thing. I limit the styles in this sheet to root elements only – no classes or ids. Anything requiring a class is probably going to be site-specific and so belongs in layout.


Forms are my least favorite things to try and style - the variation between browsers often forces lots of ugly hacks and filters and I like to keep these separate from the rest of the CSS.


How often have you coded a horizontal nav bar? Do it once, do it well, and reuse it. You’ll need to tweak a few bits and pieces but put it in it’s own CSS file and the bulk of the work will be a copy and paste away.


This is where the majority of the work lies and most of it will be unique to the project you’re working on. I use naming conventions for my common structural elements to ease the transition between sites when it come to maintenance but that’s off-topic for this article.

Color scheme:

The only properties you’ll need in here are: color, background and border-color. Nothing else. Be sure to avoid adding any layout info here – a misplaced margin:0 can ruin your whole afternoon!

An added benefit of the separate color stylesheet is that you can write yourself a nice neutral colour scheme and avoiding 10 hours per day of staring at the eye-searing orange that your client is insisting on.

On a similar note: Stop Design | Introducing Bleached.

Possibly of interest here: And All the Malarkey | Black and white: Day five.

Putting them all together

I use a file called screen.css but it can be whatever you like. All you’re doing here is @importing your CSS modules to make up a complete site. The @imports cover N4 degradation so you can just <link> to screen.css from your HTML.
/* typography styles */
@import url("typo.css");
/* form elements */
@import url("forms.css");
/* main layout */
@import url("layout.css");
/* navigation */
@import url("horizontal-nav.css");
/* colour scheme */
@import url("skin.css");

For your print stylesheet you might choose to just import your typography. Rather than having a print sheet that overrides all your layout just have it import typo.css and nothing else. Job done. What about hand held media types? Well you might want a flexible layout but the same typography, form styling and color scheme. Modular CSS comes to the rescue and you only need to code a new layout and import it into handheld.css along with typo.css, form.css and skin.css.

This technique also allows you to unplug stylesheets globally from your site without having to touch the HTML, adding a layer of abstraction between content and style.

Another happy side benefit of modular CSS is in the debugging – just comment out whole stylesheets until you isolate the problem and focus your efforts there.


You could plug in a development stylesheet with Andrew Krespanis’ Global Whitespace Reset (Left Justified | Global White Space Reset). Before you hand over just remove the import from screen.css and you’re good to go.

If you find that your’re reusing chunks of code from previous projects for promo boxes of headers, consider placing them in their own stylesheet for easier access later.

A word of caution

The more stylesheets you have the more you, the developer, have to remember and keep track of. Where did you set the padding on that element? It could be in a number of places and if you’re not used to your system, or you’re not consistent with it, things can get frustrating. Set yourself some guidelines and stick to them to give yourself a fighting chance of taking an educated guess at where you might have placed your rules. Consider putting these guidelines in comments at the top of your files – these can help to keep you on topic while you’re coding as well as setting you off running when you come to make maintenance changes months down the line. Something as simple as sensible naming conventions for your CSS files can be a great help.


Tags: , , , , , ,


Posted in CSS. 324 views
Responses are currently closed, but you can trackback from your own site.

No Comments

Sorry, the comment form is closed at this time.