Jens Oliver Meiert

CSS: Simple Rules for Better Organization and More Efficiency

Post from May 15, 2008 (↻ December 12, 2016), filed under .

This and many other posts are also available as a pretty, well-behaved e-book: On Web Development. And if you’re only interested in a robust overview on coding guidelines, check out my little book on it: The Little Book of HTML/CSS Coding Guidelines.

“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 enough “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 (by the way, this is what I referred to when announcing CS4 in January).

Sort and Group by Selectors

Web developers taking the “module approach” tend to do this already, but it is quite 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 “vertically” and “horizontally”:

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

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

This is a rather rough description of what I use and with what I had good experience. Use it as a 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 it 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.

Note:

Alphabetically Sort Declarations

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 sizes, 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 some friends, too, but I claim that this is the simplest and most straightforward once you get used to it.

Example

Let’s use WHWS’s 2006 standard style sheet to apply all these tips in 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; }
}

❧ At the end of the day, use what’s best for you. If you feel inspired by these rules try them on for size in some smaller projects.

About the Author

Jens Oliver Meiert, photo of December 23, 2018.

Jens Oliver Meiert is a developer and author (sum.cumo, W3C, O’Reilly). He plays with philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.

There’s more Jens in the archives and at Goodreads. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Comments (Closed)

  1. On May 16, 2008, 0:42 CEST, Duluoz said:

    Great article as always Jens.

    Choosing a great mono-spaced typeface also helps you be more efficient in working with any code. There are many typefaces created specifically for making code easier to read and comprehend quickly. Just like serifs help us read a newspaper or a book comfortably, so will a mono-spaced typeface help us see code more comfortably.

  2. On May 16, 2008, 9:45 CEST, Jens Oliver Meiert said:

    David, thank you. Concerning fonts for code, I intentionally take this approach in order to avoid the problem that the code font does not typographically fit the usual type. But this may change once I find a working alternative 😊

  3. On May 16, 2008, 11:19 CEST, Alan Gresley said:

    I do believe the best way to learn organization in one’s CSS is to have dis-order first and while you fixing this dis-order, you’ll remember not to make the same mistakes again.

    You can apply that to many things in life, even the development of the web.

  4. On May 16, 2008, 16:00 CEST, Trevor Davis said:

    I agree 100% about alphabetizing CSS properties. I started doing it about a year ago, and now I cannot imagine doing anything else.

    It also helps a lot for consistency when you are working with a team of people.

  5. On May 17, 2008, 3:36 CEST, Jens Nedal said:

    I like the alphabetical order approach for declarations.
    In our team we use a background ro foreground and outside to inside approach, looking at the box model.

    like 

    ... {
background:  ...
margin: ...
padding: ...
border: ...
...
} ...

    This suited us well since the boxmodel is something that is always in your head. Its more along the lines of your selector sorting and grouping. Not totally adhereing to the boxmodel order.

  6. On May 19, 2008, 15:33 CEST, Alan Gresley said:

    Jens, I’d suspect there to be inconsistencies, or did you really have good experience with that approach, has there been enough “discipline”?

    I would go along with Jens Nedal’s approach but in a different order (seen in my CSS), like:

    font-size: ..
width: ..
height: ..
padding: ..
margin: ..
border: ..
background: ..

    Then repeated rulesets later in the cascade for progressive enhancement and hackery.

    I almost always have background last since mine usually take up a whole line. 😉

  7. On May 20, 2008, 18:40 CEST, Duluoz said:

    To be honest - I never gave a rats behind about the order of the selectors. I work with several other developers right now and we just throw any old selector anywhere (outside of how we want things to inherit obviously). I can’t say that I’ve ever been “confused” or misunderstood something because of the order.

    You know the scene in the movie “The Matrix” where the guy is looking at all the code flying down the screen and he says he just learns to “see the matrix, not the code”? Thats kind of how myself and anyone I know that deals with CSS everyday sees things. We see it all as a whole.

    I think its a nice habit to have, don’t get me wrong, I just never put much value in it.

  8. On May 25, 2008, 1:53 CEST, Jordan Clark said:

    I’m another fan of alphabetizing CSS properties. It just makes sense, and helps to ensure that you never redeclare a property by accident.

    However, that’s not to say that I don’t make the odd exception to this rule. For instance, with the position property, I like to keep the directional values (top/right/bottom/left) directly below it so that I can quickly work out what’s happening, e.g.:

    .example {
    border: 1px solid;
    font-weight: bold;
    position: relative;
    top: 10px;
    left: 10px;
    width: 100px;
 }

    (It makes sense to me, anyway!)

  9. On July 2, 2008, 0:20 CEST, Tedel said:

    I liked your article. My congratulations.

  10. On October 10, 2008, 22:02 CEST, Joel said:

    I just wrote a tool that converts single-line and multi-line css.

  11. On July 9, 2009, 21:32 CEST, Jonny Axelsson said:

    I follow a “Most important first” organisation of properties, starting with layout properties like ‘display’ and ‘float’, generated content, box model, colour, typography, and aural properties.

    The rationale is simple, it makes debugging easier, you can quickly scan to likely point of error. However it probably would fail with a large organisation and it depends on everyone having a good command of the entire CSS 2.1 vocabulary. With the much larger CSS3 vocabulary it would be considerably harder to maintain.

  12. On December 25, 2009, 18:40 CET, Steffen said:

    As far as I understand the grammar from the css specification
    '{' S* declaration [ ';' S* declaration ]* '}' S*
    or the verbal explanation (”semicolon (;) separated groups”) the trailing semicolon in the declaration block is not only unnecessary but also invalid.
    I have to admit that I couldn’t find the reason why the validator doesn’t list it as an error though.
    Come on Jens, save some more bytes and remove the semicolons for the sake of your never ending quest for speed 😉

  13. On April 16, 2010, 16:50 CEST, Andre said:

    Great contribution. Found it via smashing magazine

  14. On May 5, 2010, 0:51 CEST, Henk said:

    This: “Use any declaration just once so it takes less time to load” is a very good tip.

    How do you sort your declarations alphabetically when you have grouped some of them?

Read More

Have a look at the most popular posts, possibly including:

Say hello on Twitter or LinkedIn.

Looking for a way to comment? Comments have been disabled, unfortunately.

Found a mistake? Email me, jens@meiert.com.

You are here: Home → Archive → 2008 → CSS: Simple Rules for Better Organization and More Efficiency

Last update: December 12, 2016

Awareness, honesty, responsibility.