Structuring CSS is not a trivial task, especially in large projects. Even smaller systems may become complex and hard to maintain when introduced to RWD. In this post I’ll describe how I approach implementing larger sets of CSS rules.
An aspect of my career is my work with CSS, which has proven to be a tool somewhat harder to master than first anticipated. One dimension is the building blocks described by the standards. Another dimension is how these standards are interpreted and implemented by the various browsers (and how their differences create headaches long after their release). Yet another dimension is how these rules are combined, giving leeway to several techniques that become de facto standards for how to solve certain problems that arise again and again.
Finally, there is the dimension of magnitude. As web projects grow, there is high probability that their CSS rules will grow too. As such, some ideas for how to keep your rules structured in an intuitive and clean way are nice to have. To help guide us, we can probably learn from knowledge amassed in our community. As web developers, we like to bundle that knowledge into acronyms that describe certain principles.
- DRY: If you’ve solved a problem once, re-use that solution.
- DRO: If others have solved a well-known, defined problem once, why don’t re-use their solution?
- SoC: Rules that grouped into sensible expressions are more easily reused.
I’ve focused these TLAs on the need of re-usability. The level of re-usability is, in my opinion, the number one driving force in helping us to keep our CSS rules maintainable. It may also help us in our design, as it may hint that certain design choices introduce unnecessary amount of CSS rules, and that we should try to reuse our existing first. This may lead to a more consistent design, keep us away from unnecessary clutter, and allow us to follow another principle that’s been abbreviated, namely YAGNI.
So, with all this in mind, how should the structure look like? My best tip is to draw upon the features of CSS, starting with selectors. The essence are ids, classes, tags, pseudo-selectors and the universal selector (*). Using this as base also corresponds better with CSS specificity which can be a real pain in the ass when not considered.
Another tip is to use a dynamic stylesheet language, like LESS or Sass, as they drastically ease the work of writing CSS by introducing variables, nesting, mixing, operators, and functions. Related to the latter is CSS framework that are aimed at authoring CSS, focusing more on introducing mixins for explicit use by the implementer. I can recommend Compass, but inuit.css may also be interesting to take a look at. Both of these are based on Sass, and currently I’m inclined to use Sass over LESS, but it really depends on your personal taste.
In addition to dynamic stylesheet languages and authoring CSS frameworks, there are several other kinds of frameworks that have a greater impact at guiding our design. On my workplace we’ve introduced Bootstrap with success, and it has increased the rate of prototyping tremendously. Other frameworks are YUI CSS, Foundation, Blueprint, and Skeleton. They also guide some decisions, which may be good or bad depending on how you look at it. Common for all are that they introduce specific design elements, such as typography, form styles, navigation elements, buttons, icons, etc, enabling you to get something good-looking quite fast. As such, I wouldn’t recommend combining them, as their use of semantics may differ.
A last slew of CSS frameworks are those targeting specific features. Perhaps the most popular these days, with RWD being such a trend, is the one focusing on grids. Popular amongst these are 960.gs, 1140px, and Less Framework 4. These are good starting points, and may be a easy template for people not good with design (myself included), but if you truly want something that is yours, then you need to look at how designers create grids. If you need more convincing, read The Infinite Grid at A List Apart, and/or if you want to learn a little bit more about the basics of grids, check out Rolling Your Own Grid Layouts on the Fly Without a Framework at Design Shack.
Now, finally, lets look at an example, namely the structure used for the theme used by this blog (unless I’ve gone tired of it and changed it, of course), minimalist. It’s written in Sass, and makes use of Compass and a customized version of Bootstrap (thanks to their very nice customize-tool). One final note is that I use ems as the measure unit for my design.
The structure is as follows:
| lib |- bootstrap.min.scss |- bootstrap.scss | mixins |- grid.large.scss |- grid.medium.scss |- typography.scss | patterns |- block.large.scss |- block.medium.scss |- block.scss |- bootstrap.scss |- tags.medium.scss |- tags.scss | unique |- master.large.scss |- master.medium.scss |- master.scss |- rss.large.scss |- rss.scss | variables |- color.scss |- dimension.large.scss |- dimension.medium.scss |- dimension.scss | style.large.scss | style.medium.scss | style.scss
The five directories are lib, mixins, patterns, unique, and variables. These are included by the various style files, which themselves are linked to by using mediaquries in the tags, e.g.
<link rel="stylesheet" type="text/css" media="all and (min-width: 30em)" href="minimalist/style.medium.css" />. The only responsibility the style-files has, is to include the necessary files for the different modes, in the correct order. First of all the order ensures that dependencies are handled, secondly it reflects the CSS specificity, e.g.:
@import "compass/reset"; @import "lib/*"; @import "variables/*"; @import "mixins/*"; @import "patterns/*"; @import "unique/*";
The different style files represents the different steps, and somewhat mimics the width of a mobile, pad, and desktop viewport. But this is a truth with modifications, as I use em as the basic unit of the design, which means it really depends on whatever default font-size the user has.
This structure also allows me to reuse components between size-dimensions, as exemplified by
mixins/grid.large.scss that imports from
mixins/grid.medium.scss. This is done so that the *.large files uses the variables defined in
variables/dimension.large.scss, but reuses the components defined in grid.medium.
As minimalist is quite, well, minimal, it doesn’t contain that many rules (19,15KB altogether, with comments and not minimized), but I have pretty much the same setup at work, and there it works splendidly, with lots of lots of rules.
The last note will be on the process of writing rules. Another aspect my approach is that it guides the naming of components, with (mostly) all of the rules in pattern prefixed with the name of the file in which it is located, e.g.
.block-container is in
#MasterAside is located in
unique/master. This guideline allows for quick debugging, and speeds the process of discovering (which is an issue I probably will write more on later).
An exception to the naming conventions are the files
patterns/tags. The former gives “overrides” to the rules implemented in the
lib/bootstrap (e.g. if I want my own style at buttons), while the latter is default rules for tags. As a general rule I try not to write to many rules concerning tags, as they quickly become excessive (remember SoC), but e.g. links are in general a certain color, and that should be expressed.
Hope you have enjoyed reading about my tips on structuring and writing CSS rules, and if you have some of your own, I would love to hear them.