In software development, there’s this set of principles called the SOLID principles. As with most things in computer science, it’s yet another acronym in which each letter stands for the following:

  • Single-Responsibility
  • Open/Closed
  • Liskov Substitution
  • Interface Segregation
  • Dependency Inversion

Though these ideas are geared towards software engineering and object-oriented design, there’s one principle that I think is relevant to front-end web development (well, actually a few but I digress for now).

Specifically, I think the idea of the single-responsibility principle is applicable to CSS – namely, within the popular LESS and Sass preprocessors.

CSS Single Responsibility

According to Wikipedia:

The single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Doesn’t sound very applicable to stylesheets with all of this talk about classes and encapsulation does it?

Bear with me.

A Brief History of CSS

When CSS first hit the scene, it was pretty awesome – I mean, we finally had a way to separate the style of the markup from the markup of the data. The thing was, developers usually piled all of their CSS into a single file.

As the web became more complex, developers began to create separate files for each of their pages in order to isolate some of the unneeded files. After that, the CSS then introduced `@import` which made it possible to create separate files and then import those separate files into a single file.

So, as you can see, from early on we’ve been working to try to make CSS more modular – well, for lack of a better term.

Then preprocessors came along that allowed us to introduce nested rules, mixins, variables, and so on – it essentially extended CSS to include features that programming languages have had since they’ve been around.

And, of course, we still have the ability to separate files and import them into a single file when needed.

Now On To LESS, Sass, and More

So after that history lesson, we’re now actually at a point where we’ve got a lot of features in CSS, but we’re still faced with a set of challenges that have been around from the beginning.

Namely, how modular should our stylesheets be?

As this relates to the single-responsibility principle, I consider it something like this:

Each LESS/Sass file should be responsible for providing the set of styles for a single set of elements, page, template, or view.

For example, the structure of my LESS files often look like this:

/* Table of Contents
 * - Color Palette
 * - Mixins
 * - Bootstrap Resets
 * - Elements
 * - Classes
 * - Body
 * - Navigation
 * - Social Icons
 * - Primary Content Wrapper
 * - Footer
 * - Media Queries

/* Color Palette
@white:         #ffffff;
@off-white:     #fcfcfc;

@black:         #000000;
@off-black:     #050505;

/* Mixins

.align_navigation() {

} // align_navigation

.collapse_lr_padding() {

} // collapse_lr_padding

.center_header() {

} // center_header

.rounded_image() {

} // rounded_image

.header_font() {

} // header_font

.post_title_font() {

} // post_title

/* Bootstrap Resets

.collapse {

} // .nav-collapse

.caret {

} // .caret

/* Elements

body {

} // body

a {

} // a

code {

} // code

h1, h2, h3, h4, h5, h6 {

} // h1, h2, h3, h4, h5, h6

/* Classes

.alignleft {

} // .alignleft

.alignright {

} // .alignright

/* Header

#masthead {

} // #masthead

/* Navigation

#top-navigation-wrapper {

} // #top-navigation-wrapper

.navigation {

} // .navigation

/* Social Networks

#social-networks {

} // #social-networks

/* Primary Content Wrapper

#primary-wrapper {

} // #primary-wrapper

/* Sidebar

/* Footer

#footer-wrapper {

} //#footer-wrapper

/* Media Queries

/* Handheld */
@media (min-width: 320px) and (max-width: 568px) {

} // handheld

/* Tablet */
@media (min-width: 600px) and (max-width: 800px) {

} // tablet

Obviously, this is just an example but it drives the point home: I separate sections of my code based on what they are responsible for styling.

This way, it makes it easy to locate and find the area of the styles with which I need to work, and it’s usually structured in such a way that it roughly matches my mark up.

The thing is, this gets really hairy to maintain over time, especially when you’re done with a single stylesheet.

To that end, I kind of consider a single stylesheet like a god-stylesheet (which is a nod to a god-class or a god-object, in object-oriented programming). In short, the stylesheet ends up knowing everything about the entire site when, in reality, maintenance would be much easier if we broken them out into separate files such as:

  • `global.less` which would include variables and mixins
  • `resets.less` which are used to reset the markup or reset elements based on the framework that’s being used
  • `general.less` which would be the file in which all general elements (like `body`, `h1`, `p`, `span`, `a`, and so on are styled
  • `header.less` which is obviously responsible for styling the header
  • `footer.less` which is responsible for styling the footer
  • …and so on

In short, the idea is to give each file a single responsibility.

Of course, this comes with its own set of gotchas just like everything else: From a development standpoint, it’s really convenient. Working on the header? Open `header.less`. Working on the sidebar? Open `sidebar.less`.

But we still have the problem of combining and minifying the files.

I know that there are some purists out there that will claim that we need to only serve up the styles that are applicable to a given page, but I’m more of the mindset that keeping things separated – that is, giving CSS single responsibility – in development is fine, but we should aim to serve up one minified version of the stylesheet.

That way, developers and designers are able to maintain their files logically, consistently, and easily, and we’re able to serve up a single file that results in a single request and that the browser and the caching system can store.

At least, that’s my take on it for now. But if you’ve got other opinions and better practices, I’m all for ’em.