A blog post titled Things To Avoid When Writing CSS caught our attention a few days ago. We appreciate the author’s point of view, but we just couldn’t bring ourselves to agree on all the points raised.

We thought it would be useful if we shared our experience and views on how to write efficient and maintainable CSS.

A CSS file is an ordered set of rules, so when writing CSS, a developer should always pay attention to the order of the rules.

Even a small project can rely on a CSS file that can grow quite large. As the project grows, the CSS file becomes bigger and bigger. Eventually, keeping track of all those rules becomes hard, and even a small change becomes fertile ground for your baldness.

While writing HTML or JavaScript, you organize it in multiple files. You should follow the same principle while writing CSS. It’s easier to find related information as it is grouped in separate files. Also, when a versioning system is used, more people are able to work on the project with less merge conflicts.

As for the specificity argument, if a rule depends on another rule, both of them need to be in the same file. In that way, it’s easy for you to manage that dependency.

You should always be aware that your files will generate one big CSS file and that, in some cases, the order of CSS files is crucial.

As a rule of thumb, we try to keep our SASS files under 200 lines of code with optimal length of around 100 lines per file. Also, complicated blocks that have over 50 lines of code should go into separate files.

From our experience, the modularization of CSS pays off even in cases when a single developer works on the project. Furthermore, the benefits of modularization increase with more developers working together.

Summary: Split your CSS code into different files and then use one main file to manage the loading order. Be wary of specificity as you would be if it was all in one file. Keep individual files under 200 LOC.

Nesting improves code readability and eliminates duplication. Most problems with nesting come from not understanding what the generated CSS will look like.

That being said, there’s no good excuse for not using it. Someone who writes SASS code with obnoxiously deep nesting would probably also write lousy non-nested CSS. For them, nesting is just another tool to shoot themselves in the foot.

We use BEM methodology and keep our nesting no more than three levels deep. There are some exceptions where we use four levels of nesting. This keeps our generated CSS code relatively flat.

Summary: Nesting in SASS is NOT inherently a bad thing and you should use it. However, in general, it should be no more than three levels deep.

Using measurement units other than pixels is great, but you just can’t use them for some designs. There is a reason why it’s called pixel perfect. A designer has a vision of what the design should look like. By using pixel measurements, a developer has full control over the sizes, which is sometimes necessary.

This doesn’t mean that you shouldn’t use relative measurement units (em, rem, %, etc.). They are useful and powerful for elements that change depending on the screen size.

Summary: Using relative units of measurement is great, but they aren’t applicable to every metric in your CSS.

This is actually the part of the article we agree on the most. There are many different devices with different screen sizes and, of course, you won’t have breakpoints for every single one of them.

Summary: Determine the number of breakpoints based on the design. A few breakpoints are usually enough.

CSS is not a programming language (rather a stylesheet language), but there are a lot of good programming practices from other languages we can learn from and apply them to CSS.

Also, there are plenty of tools today that help us write cleaner CSS with less “I want to kill myself” moments. By using these modern techniques/rules/guides/tools, our CSS becomes cleaner, maintainable and easier to work with.

The key is understanding what is going on with your code, how the language works behind the scenes, and what your code will generate. After that, situations like Peter’s will be less frequent.