CSS: Simple Rules for Better Organization and More Efficiency

Published on May 15, 2008 (updated Jul 11, 2024), filed under development, css, maintainability, performance (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. If the optimization of CSS is of particular import to you, I’ve collected several concepts in a brief book: CSS Optimization Basics.

“Organization is not everything, but without organization, everything is nothing,” one of my teachers used to say. Almost everything benefits from organization, and so does work with CSS—especially when working with many people. During the years I took special care of organizational standards for HTML and CSS (German readers might know the coding guidelines I created for GMX and Aperto), and there are plenty of “proofs of concept.”

Then, over time I refined my personal CSS coding guidelines. Here I want to share three basic rules I use for consistent organization and improved efficiency (which, by the way, is what I referred to when announcing CS4 in January).

Sort and Group by Selectors

Web developers taking the modular approach tend to do this already, but for everyone it’s worthwhile to standardize selector order, both for yourself and for the team involved. In my projects I currently use the following order (although not including all elements):

*, html, body, h1, h2, h3, h4, h5, h6, p, address, blockquote, pre, ul, ol, li, dl, dt, dd, table, caption, tr, th, td, form, fieldset, legend, label, input, textarea, div, img, a, strong, em, abbr, q, cite, code, kbd, var, span, #id, .class

This sorting method works both “horizontally” and “vertically”:

ul, li, .note {}
ul {}
li {}
.note {}

The rule gets slightly more complex when including descendant selectors; I like to apply the same order (e.g. p em, p abbr {}), but let simpler selectors go first (p, p em, p abbr {}). Another subrule worth mentioning is the order applied to selectors, like p and p.warning, where it would be p, p.warning (or p, .warning, fitting the above scheme again), both horizontally and vertically, too.

This is a rather rough description of what I use and with what I had good experience. Use it as the foundation; for instance, you might opt for a “module-centric” approach by applying this order within CSS sections like navigation styles rather than whole style sheets.

Update (February 14, 2013)

I published a comprehensive draft to order CSS selectors.

Use Any Declaration Just Once

Exactly: Use any declaration just once. The reason for that is that on average, declarations are longer and thus add more weight to style sheets than selectors (and selector groups), and thus take more time to load. Another reason is that “UDJO” reduces the need for CSS variables (not: selector variables)—in many cases you don’t need them at all.

Let’s see a short but realistic example:

h1, h2, h3 { font-weight: normal; }
a strong { font-weight: normal !important; } /* exemplary, take it as given */
strong { font-style: italic; font-weight: normal; }
#nav { font-style: italic; }
.note { font-style: italic; }

Applying the “any declaration just once” rule results in

h1, h2, h3, strong { font-weight: normal; }
a strong { font-weight: normal !important; }
strong, #nav, .note { font-style: italic; }

This saves a few characters (and load time) without getting into the way of maintenance.

Note:

• Overly long selectors can drive this method useless. Repeating selectors like html body table tbody tr td p span.extraordinary-class-name in order to have unique declarations doesn’t save much—it might instead be a signal to use more compact selectors.

• Be aware of CSS constraints: When a user agent can’t parse a selector, it must ignore the declaration block as well. If you run into trouble with this because of, say, hacks, just bend the rule accordingly, i.e. use the declaration in question twice.

• Keep the cascade in mind when using this rule in conjunction with the sorting one.

• This organization and efficiency rule requires more attention when maintaining style sheets. Find a way to track changed and added declarations in order to keep them used only once, too—this is not hard when using a more or less reasonable editor (showing line changes, for example), but needs to be incorporated into your workflow.

Update (October 26, 2017)

I published a comprehensive guide to use declarations just once.

Sort Declarations Alphabetically

There are I-don’t-know-how-many ideas how to sort declarations within declaration blocks, but the simplest and “cognitively least demanding” is alphabetical sorting. So instead of thinking measurements first, then colors, then dimensions, and so on, just order alphabetically:

#content {
  border: 1px dashed;
  color: #000;
  margin: auto;
  padding: 1em 0;
  width: 700px;
}

I know that other sorting methods (or no sorting at all) have friends, too, but I’m certain that this is the simplest and most straightforward one.

Example

Let’s use WHWS’s 2006 standard style sheet to apply all these tips to one style sheet:

@media screen, projection {
* { margin: 0; padding: 0; }
html { background: #000; color: #ccc; font: 87.5%/1.5 optima, arial, sans-serif; text-align: center; }
body { margin: 1em 0; }
h1, h2 { font-size: 1em; font-weight: normal; }
h1 { background: url(/media/logo.jpg) no-repeat; height: 366px; text-indent: -999em; width: 620px; }
h2, p { margin: 0 .5em; }
p + p { text-indent: 1em; }
p#ref { background: url(/media/end.jpg) no-repeat bottom center; margin: 1.5em 0 0; padding-bottom: 179px; }
ul { margin: .5em 0 .5em 1.5em; }
ul#lang { list-style: none; margin: .5em 0 1em 1.5em; }
ul#lang li { display: inline; }
div#show { margin: auto; text-align: left; width: 619px; }
div#whws { background: url(/media/tape.gif) repeat-y top center; margin: 42px 0; }
div#whws + div { position: relative; }
a, strong { color: #fff; }
strong { font-size: 1.3em; line-height: 1.0; }
kbd { font-family: optima, arial, sans-serif; }
}

❧ Ultimately, use what’s best for you. If you feel inspired by these rules try them on for size in smaller projects.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)