Free Online Courses for Software Developers - MrBool
× Please, log in to give us a feedback. Click here to login

You must be logged to download. Click here to login


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

CSS Guidelines

This article will talk about Guidelines to write CSS. Reading this you will be able to start to learn and write your own CSS.

A very common problem when working in a team is the inconsistency in coding style. Some prefer to put the CSS properties in a single line, others do not. Some like to put space after the colon, others do not. In the end, it's all over an area. Many developers writing in ways completely different, this undermines any maintenance and evolution of code.

In today’s programming world maintaining coding standard and best practices are as important as developing the business logic. So I have noticed a growing movement of companies seeking to standardize their coding style. Google, Github, and many others have made available publicly their style guides:

Thinking about it, Nicolas Gallagher , official Twitter, creator of Normalize.css and a leader of the HTML5 Boilerplate, decided to create a guide called Idiomatic CSS - CSS principles to write consistently and idiomatic based on a similar project, but with a focus on JavaScript, the idiomatic.js .

The following guide is not intended to be prescriptive and does not seek to impose the preferences of the author in other people's code. However, these guidelines strongly encourage the use of existing standards, common and sensible.

General principles

All code in any application should look as if it had been written by a single person, regardless of how many people have contributed. Do strictly comply with the agreed style.


Again, just a style exists in every project. Always be consistent in the use of blanks. Use white space to improve readability.

  • Never mix tabs and spaces for indentation.
  • Choose between smooth indentation (spaces) or tab. Stick to your choice without fail.(Preference: spaces)
  • If you use spaces, choose the number of characters used for indentation level.(Preference: 4 spaces)

Hint: configure your editor to "show invisible." This will allow you to eliminate blanks line break, remove whitespace indentation without empty lines and avoid polluted commits.


Well commented code is extremely important. Take time to describe components, how they work, their limitations and how they are constructed. Do not let the other team to guess the purpose of codes unusual or unobvious.

Comment style should be simple and consistent within a single code base.

  • Put comments on a new line above your subject.
  • Avoid comments at end of line.
  • Keep the line length to a maximum sensible, for example, 80 columns.
  • Make liberal use of comments to break the CSS code in separate sections.
  • Use comments capitalized and indentation consistent text.

Hint: configure your editor to provide you with shortcuts to generate the pattern of comments agreed.

Listing 1: CSS Example

/ * ======================================== ==================================  
Block comments section  
=========== ================================================== ============= * /
/ * Block comment of sub-section  
========================================= ================================= * /
/ *  
block comment * group  
* Ideal for multiple lines explanations and documentation.  
* /
/ * Basic * Comment /  

Listing 2: Example with SCSS

/ / ======================================== ==================================  
/ / block comment section  
/ / ======= ================================================== =================
/ / Block review of sub-section  
/ / ======================================= ===================================
/ /  
/ / comment block group  
/ / Ideal for multiple lines explanations and documentation.  
/ /
/ / Comment basics  


The code format chosen must ensure that the code is: easy to read, easy to comment clearly; minimize the chance of accidentally introducing errors, and result in useful views of difference.

  • A selector per line in a discrete set of rules with multi-selectors.
  • A single space before the opening of the keys in a set of rules.
  • A single statement per line in a declarative block.
  • An indentation level for each statement.
  • A single space after the colon in a statement.
  • Always include a point-colon at the end of the last statement in a declarative block.
  • Place the closing of the keys in the same column as the first character of the set of rules.
  • Separate each set of rules by a blank line.

Listing 3: Formatting

. dial-1  
. dial-2  
. dial-3 {  
-webkit-box-sizing: border-box;  
-moz-box-sizing: border-box,  
box-sizing: border -box,  
display: block;  
color: # 333;  
background: # fff;  

Declaration order

Statements should be ordered according to a single principle. My preference is for related properties to be grouped and structurally important properties (eg, positioning and box-model) to be declared before typographic properties, background or color.

Listing 4: Declaration order

. dial {  
position: relative;  
display: block;  
width: 50%;  
height: 100px;  
padding: 10px;  
border: 0;  
margin: 10px;  
color: # fff  
background: # 000;  

Alphabetical ordering is also popular, but the downside is that it separates the related properties. For example, position offsets are no longer bundled and properties of the box-end model can propagate over a block statement.

Exceptions and slight deviations

Large blocks of individual statements can act differently, through the single-line formatting. In this case, a space should be considered after the opening of the keys and before the closing of the keys.

Listing 5: Exceptions and slight deviations

. dial-1 {width: 10%;}  
. dial-2 {width: 20%;}  
. dial-3 {width: 30%;}  

Long property values ​​separated by comma - as collections of gradients or shadows - can be organized on multiple lines in an effort to improve readability and produces more useful views of difference. There are various formats that could be used and an example is shown below.

Listing 6: Another ways to use

. dial {  
1px 1px1px # 000  
2px 2px # ccc 1px 1px inset;  
linear-gradient (# fff, # ccc),  
linear-gradient (# F3C , # 4EC);  


Use hexadecimal values ​​in lowercase, for example: # aaa

Use single or double quotes consistently. Preference for double quotes, for example: content: "".

Always put quotation marks around attribute values ​​in selectors, eg: input [type = " checkout "] Where permitted , avoid specify units for values ​​zero, for example: margin: 0.

Preprocessor: considerations additional formatting

Different CSS pre-processors have different features, functionality and syntax. Its conventions should be extended to accommodate the particularities of any pre-processor in use. The following guidelines are in reference to Sass.

  • Limit nesting to one level deep. Reassess any nesting that has more than 2 levels deep. This prevents there are very specific CSS selectors.
  • Avoid a large number of nested rules. Break them for when readability start to be affected.
  • Preference for nesting to avoid spread over 20 lines.
  • Always put the statements @ extend the first lines of a block declarative.
  • When possible, group declarations @ include atop declarative blocks after any statement @extend .
  • Consider custom functions for prefixes with x- or any namespace. This helps avoid any potential confusion in their function with the CSS native or colliding with library functions.

Listing 7: Miscellany

. dial-1 {  
@ extend. other-rule;  
@ include clearfix ();  
@ include box-sizing (border-box),  
width: x-grid-unit (1);  
/ / other statements  


You are not a compiler / compressor human code, so try not to be.

Use clear and farsighted names for HTML classes. Choose a pattern of consistent and understandable names that make sense to HTML and CSS files.

Listing 8: Naming

/ * Example code with bad names * /
. S-scr{  
overflow: auto;  
. Cb{  
background: # 000;  
/ * Example code with good names * /
. Scrollable is-{  
overflow: auto;  
.-Column body {  
background: # 000;  

Practical Example

Listing 9: An example of several conventions

/ * ======================================== ==================================  
Grid layout  
============== ================================================== ========== * /
/ *  
HTML * Example:  
* /
. Grid{  
overflow: visible;  
height: 100%;  
white-space: nowrap;  
font-size: 0;  
. {Cell  
box-sizing: border-box;  
position: relative;  
overflow: hidden,  
width: 20%;  
height: 100%;  
padding: 10px 0;  
border: 2px solid # 333;  
vertical-align: top;  
white-space : normal;  
font-size: 16px;  
/ * Cells - State * /
. {  
background-color: # fffdec;  
/ * Cells - Dimensions  
============================================= ============================= * /
. 1-cell {width: 10%;}  
. 2-cell {width: 20%;}  
. 3-cell {width: 30%;}  
. 4-cell {width: 40%;}  
. 5 {cell-width : 50%;}
/ * Cells - Modifiers  
============================================= ============================= * /
. Cell-detail,  
. important cell-{  
border-width: 4px;  


Organization code is an important part of any CSS code base, and crucial for large code bases.

  • Logically separate different parts of the code.
  • Use separate files (concatenated with a build process) to help divide code for distinct components.
  • If using a pre-processor, abstracting common parts of code variables for color, typography, etc..

Build and deploy

Projects should always try to include some generic means by which the source can be evaluated, tested, and versioned compressed in preparation for production use.


Regardless of whether or not you have agreed with the proposed style guide, it is important to understand how to standardize the coding style can help you and your team. Think about it.

I''m a full stack developer with around 10+ yrs of experience. I enjoy writing technical articles on upcoming technical trends.

What did you think of this post?
To have full access to this post (or download the associated files) you must have MrBool Credits.

  See the prices for this post in Mr.Bool Credits System below:

Individually – in this case the price for this post is US$ 0,00 (Buy it now)
in this case you will buy only this video by paying the full price with no discount.

Package of 10 credits - in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download few videos. In this plan you will receive a discount of 50% in each video. Subscribe for this package!

Package of 50 credits – in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download several videos. In this plan you will receive a discount of 83% in each video. Subscribe for this package!

> More info about MrBool Credits
You must be logged to download.

Click here to login