CSS formatting guide

As we summarize a recent survey on sorting CSS properties , we have more serious questions about CSS formatting style. Sorting properties is just one step on your way to a complete style formatting strategy. The name of the class is part of the strategy. Distribution is part of the strategy. Comments, indents, file structure ... all this forms a guide to CSS formatting.

Let's look at existing formatting practices.

But first ... We will not talk about libraries.

I love libraries. Twitter Bootstrap or GEL . I believe that these are fantastically convenient tools for working with sites and web applications, especially large ones. This article is not about them. We will review them a little later, since I think that such an experience will be no less valuable.

List

I will list some points I liked below.

Github

GitHub CSS Formatting Guide →

As a rule, you should not use more than 3 levels of nesting. If you have done this, then you should consider reorganizing the code (except in specific situations or when markup requires it)

Use the line-height property without units. In this case, you will not inherit the height of the line from the parent element, it will be set automatically as the height-multiplier.

Google

Google HTML / CSS Formatting Guide →

Name the classes and IDs as short as possible, but keep them as short as possible.
For example, use #nav instead of #navigation, .author instead of .atr

Use only a hyphen as a concatenation symbol, do not use other special characters. This will improve the readability and understanding of the code.
For example, .demo-image instead of .demoimage or .demo_image

Idiomatic css

Nicolas Gallagher Idiomatic CSS Guide →

Set your IDE to display "hidden characters." This will allow you to eliminate spaces at the end of lines, to eliminate an unintentional space in an empty line, thereby eliminating garbage in your commits.

Long values ​​separated by commas, such as collections of gradients or shadows, can be divided into several lines, this will improve readability and the code will become more convenient for comparison.

Use separate files for different components and assemble them into one at the building stage.

CSS Wizardry

CSS formatting guide by Harry Robert →

I completely abandoned the use of IDs in CSS. It just makes no sense to use them, plus they often cause problems.

In code comments, before the section heading, I always add the $ character. This is worth doing because when I search for this section, I will find it (by the keyword $ MAIN, not MAIN).

In situations where it will be useful for the developer to know how this CSS is applied to some HTML, I often include an HTML fragment in the CSS comment.

Smashing magazine

“Improving Code Readability with CSS Formatting Guide” by Vitaly Friedman →

For large projects or large teams it will be very useful to keep a change log.

For better readability of the code (if it is a small piece of code), it may be better to write it on one line.

Thinkup

ThinkUp CSS Formatting Guide →

If the value of the width or height property is 0, then you should not add a unit of measure to it.

Comments on the block of selectors should be in a separate line immediately before the block to which they refer.

Wordpress

WordPress CSS Programming Standards →

Use two empty lines to separate sections and one empty line to separate blocks in sections.

Selectors with a long name allow you to make the code more efficient, but at the same time, you should check whether these selectors really do what you need, because otherwise it can cause adverse consequences. Selectors with names that depend on their location in the DOM will save time, but along with this will cause a mess in CSS.

Magic numbers are bad. They are used as quick fixes on a one-time basis.
For example: .box {margin-top: 37px} .

SMACSS

Scalable and modular architecture for CSS from Jonathan Snook →

It will be difficult to tear a couple of quotes from this monster. But…

Each time you add a new style to the end of the file, you complicate the life of other developers who work on the same project. It will be harder to find there.

If everything is done correctly - the modules can be easily moved to any part of the document without breaking it.

Use only semantic elements.

More?

Does your organization use public style formatting guidelines? Share them!

PS If you notice errors / inaccuracies in the translation - write to the PM, I will correct it.