Over a million developers have joined DZone.

CSS: Simple Rules for Better Organization and More Efficiency

DZone's Guide to

CSS: Simple Rules for Better Organization and More Efficiency

· Web Dev Zone ·
Free Resource

Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.

Organization is not everything, but without organization, everything is nothing, one of my teachers used to say, and right he is. 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 mainly for HTML and CSS (German readers might know the coding guidelines I created for GMX and Aperto), and there should be enough “proof of concept”.

However, time brought additional refinement for my personal CSS coding guidelines, and I want to share the 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). I hope they mean some inspiration, please feel free to use, play with, and comment them.

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. Currently, the order I defined for selectors in my projects is this (although it does not include all selector types):

*, 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 (so e.g. p em, p abbr {}), but let simpler selectors go first (think p, p em, p abbr {}). Another “sub rule” worth mentioning is certainly 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.

Admittedly, this gets kind of a rough description of what I use and with what I had good experience. Feel free to build on that; for instance, you might go for a “module-centric” way by only applying this order within CSS segments (like navigation styles and so on) – or to make it more specific.

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 this is a nice argument to shake heads when CSS variables (not selector variables) come up – in many cases you probably don’t need them, at all.

Let’s see a realistic though shortened example (just imagine this style sheet contained, say, 50 rules):

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) already, without necessarily getting into the way: After all, styling HTML documents is about presentation, so focusing on declarations first does work well.

There are, however, four important things to note:

  • Overly long selectors can drive this method useless. Repeating selectors like html body table tbody tr td p span.extraordinary-awesomish-class-name in order to have unique declarations doesn’t save much – but it might be a sign to use more compact selectors.
  • Be aware of CSS regulations: When a user agent can’t parse the selector, it must ignore the declaration block as well. If you run into trouble with this, just bend the rule accordingly (use the declaration in question twice).
  • Keep the cascade in mind when using this rule in conjunction with the former.
  • This organization and efficiency rule requires more attention when maintaining style sheets. Find a way to track changed and added declarations in order to get them in line again – this is not hard when using a more or less reasonable editor (showing line changes, for example), but needs to be incorporated into the workflow anyway.

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 none at all) have some friends, too, but it may be claimed that this is indeed simple and straightforward once you get used to it – which happens quickly.


In order to show all these tips in action together (as well as inconsistencies on my behalf ;)), here’s a part of WHWS’s 2006 standard 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, just use what’s best for you, and be it that you feel inspired by these rules to try them in some pet projects or in the aforementioned module-specific way. Which is, actually, a good approach in quite complex projects.

Final tip: CS4 is best served with TWBHT.

Original Author

Original article by Jens Meiert

Take a look at an Indigo.Design sample application to learn more about how apps are created with design to code software.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}