(Note : this article was previously published in French a few weeks before this translation –if you have any feedback on the translation made by Nicolas Hoffmann and John Elbing, please let us know.)

The reign of disorder

Surely you have in your experience, recovered one day running a CSS that looks like this :

.new-left, .new-right {
   background:url('/layout/images/icon-new.png') 0 0 no-repeat;
	 padding-left: 30px; /* don't touch */
  display: inline-block;
  min-height: 30px;
zoom:1; /* IE */
}
.new-right {
float:left;
  display: block; /* don't know why, but don't touch */
 background-position: 100% 0;
  padding: 30px;padding-left:0;
        }
/* ================= */
/* NEW */ .jpg {line-height: 13px; min-height: 1em; }
/* NEWNEW */ .jpg {line-height: 13px; min-height: 1.2em; }

It is the perfect example of how CSS were produced before : this language is very permissive and integration was the last link of the chain, the CSS were a heap of ruins and the only rule that prevailed was… disorder..

Many voices have been raised against these bad practices. Imagine you get this on a complex integration, it is particularly unpleasant :
– * Indentation is catastrophic and hinders readability ;
– * Properties are never in the same order ;
– * The sections are not clearly identified ;
– * You cannot be sure where you are in the project ;
– * And above all we do not know how to do something without making this house of cards collapse !

With the rising complexity of projects, it becomes very important to organize ourselves and agree on conventions for writing CSS. Conventions help to design, but they also make maintenance much easier. Let us add that if you have to update a CSS, you will be more inclined to maintain it carefully if it is already well structured.

Examples of conventions

There are many, there are almost as many as front-end developers ! :)

These conventions can sometimes surprise with their level of detail, but this rigor brings unparalleled comfort in the usage of a style sheet, even during conception.

In general, the following are described :
– * The different block comments (overall structure, subpart, help, etc.) ;
– * The choosen indentation : spaces / tabs, the number of, etc. ;
– * Marking properties, prefixed or not, on a single line if a single property ;
– * The order of the properties ;
– * Atomic classes available ;

• etc.

Here are some example of conventions :

• Github CSS conventions ;
• Principles of writing consistent, idiomatic CSS (by Nicolas Gallagher) ;
• Improving Code Readability With CSS Styleguides, on Smashing Magazine.

If you are using CSS frameworks, they also set their conventions. For example, you may study KNACSS’s conventions.

BEM (Block Element Modifier also provides an interesting idea for CSS : indicate each module, each module child and each module modifier in the way of naming classes :

.block{}
.block__element{}
.block--modifier{}

Thus, it is possible to understand general structure and its modifications only by looking at the structure of HTML/CSS.

Let’s add to this that these agreements have effects that often go beyond the strict framework of the writing style sheets. For example, the fact of putting a single property per line greatly facilitates the display of changes to a release management tool code such as Git.

With many properties on the same line as in the example below, how do you quickly find out what exactly has been changed on the line in question ?

On the opposite, it is clear in this example below what was modified on each line.

Other tools may also facilitate this structuration effort : preprocessors like Sass or LESS allow to split CSS files in several sub-files, thereby isolating each lot of your structure of your style sheet. Thus, research and / or modification will be more effective in smaller files.

Styleguides

One or several documents identifying the style guides must be created, even if it is for internal use only. Typographic element, different blocks, global layout, etc. must be described and explained.

Here is an example (in french) : des guides de styles pour votre intégrateur.

It will already facilitate the creation of the CSS : the front-end developer will have an overall vision and detailed view of the web designer’s work, and is more likely to transcribe it faithfully. He will also have an overview of the various modules to produce.

Secondly, the newcomer during the project will have a reference document. Add to that a well ordered and well commented CSS greatly facilitates maintenance and evolution.

Finally… why not give this document to your customer ? It is a guarantee of seriousness and professionalism, sustainability, both for the site and for its CSS. It would be a shame to miss all theses benefits… and you could be the agency taking over the site.

This style guide concept can be even more important in some approaches : “styleguide driven development”.

Here are some examples :

• Kalei - Style guide
• Style Docco
• Automatic living styleguide
• Style Guide Driven Development

This approach puts documentation as a central node via a living styleguide. This may seem surprising, but at the same time, this hinders the bad practice of making styleguides at the end of the project (or never).

Conclusion

As you can see, there are lots of possible conventions and tools, the best being - in my humble opinion - the ones you choose and stick to.

Let’s say it : our CSS should be pampered and kept up with utmost rigor !

References, further reading

• CSS conventions of Github
• Principles of writing consistent, idiomatic CSS
• Improving Code Readability With CSS Styleguides
• General CSS notes, advice and guidelines
• Style Guide Driven Development
• Des guides de styles pour votre intégrateur (in french)
• La méthode FUCSS (in french)

Note

This article is part of the series “Great modern CSS conception principles”.