This is a CSS styleguide that you could fork to use for your project. Some of the rules give you multiple acceptable options. If you want to adopt this styleguide for your project, you should modify it for your project.
Here is an example styleguide made from this starting point
This styleguide follows my styleguide for styleguides. That means it follows the following rules:
- Focus on readability.
- Focus on consistency.
- Follow common practice unless you have good reason.
/* this whole thing is a rule */
selector {
property: value; /* this line is a declaration */
}
- Write valid CSS
- Use UTF-8
- Put a space after :
- Put { on same line as selector
- Put a space before {
- Put each rule on its own line
Example:
/* comment */
.egg {
color: white;
background: black;
}
Some projects choose to align style values, like this:
/* comment */
.egg {
color: white;
background: black;
}
If your project does this, do it consistently.
Only /* */ comments are valid in plain CSS
Some projects require that comments begin on a new line, but this is generally not a strict rule.
Prefer these units:
- %
- em
- px
Avoid thse units:
- in
- cm
- mm
It should be the same as the indenting used across your project, such as in JavaScript. Common options are:
- two space
- four space
- tab character
Use one of the following:
- camelCase
- dashes-are-nice
- underscores_are_ok
If you use dashes or underscores, use all lowercase.
ProperCase is not a common convention in the CSS community so you should probably not use it.
Either ' or "
Preferably the same as in your JavaScript.
I suggest omitting declaration order from your styleguide. Effectively you're deciding between spending time maintaining the order and spending time finding declarations. Since most rules contain a very small number of declarations it doesn't seem worthwhile to make this optimization.
If you feel that declarations must be in a particular order, here are some options:
You can group rules that start with the same prefix. For example, group font-family and font-size together.
You can group rules according to their function. source
You can put rules in alphabetical order. source
Do not put the same property twice in the same rule.
/* bad */
.egg {
color: red;
color: white;
}
This has no special semantics and is probably a simple mistake.
The star hack looks like this:
.egg {
width: 100px;
*width: 200px;
}
In this example, 200px width is used in IE7 and below. This is invalid CSS. A separate IE7 stylesheet might be better.
The underscore hack is the same thing but with _ instead of *.
Prefer shorthand unless there is a specific reason not to. For example:
.bad {
margin-top: 1em;
margin-right: 2em;
margin-bottom: 3em;
margin-left: 4em;
}
.good {
margin: 1em 2em 3em 4em;
}
This is not a strict rule because there are cases where longhand might be considered more readable. For example:
/* easy to miss the extra 2 properties */
.shorthand {
background: url("http://example.com/doglife/eggs/cool/backgrounds/background.png") #fff repeat-y;
}
/* more redundant but less likely to misread */
.longhand {
background-image: url("http://example.com/doglife/eggs/cool/backgrounds/background.png");
background-color: #fff;
background-repeat: repeat-y;
}
It might be appropriate to use !important in some situations, such as paving over flaws in 3rd party CSS that you don't have control over. In most situations, use of !important can be replaced with better inheritence.