cssBest Practices

The following list represents some best practices to use when writing your CSS. The examples of things not to do, in some cases, may even be valid CSS, but still are not ideal.

Write your CSS all lowercase

Do this

div {
  font-weight: bold;
}

Not this

DIV {
  font-weight: BOLD;
}

An exception to this is when you are referring to font names; writing font-family: 'Open Sans', sans-serif; in your CSS is totally okay. 👍🏻

End each CSS declaration with a semicolon

Do this

p {
  font-style: italic;
  font-weight: bold;
}

Not this

p {
  font-style: italic
  font-weight: bold
}

Technically, leaving off the semicolon on your last declaration is valid CSS, but it is not worth the headache of remembering to add it back in when you add new declarations.

Order your declarations alphabetically by property name

Do this

p {
  color: thistle;
  font-style: italic;
  font-weight: bold;
  max-width: 500px;
}

Not this

p {
  max-width: 500px;
  color: thistle;
  font-weight: bold;
  font-style: italic;
}

This seems like a lot of extra fuss as you start writing CSS, but it saves you time in debugging because you are less likely to have a property duplicated in the same ruleset if you follow this practice.

Declare box-sizing in all your stylesheets

Do this at the top of every CSS file

html, body{
  box-sizing: border-box;
}

*, *:before, *:after {
  box-sizing: inherit;
}

The browser default for box-sizing is content-box, and it is generally rubbish and operates contrary to your expectations. See this explanation of content-box and border-box for more detail.

Don’t reiterate browser defaults

Do this

h1 {
  font-weight: normal;
}
a {
  text-decoration: dotted underline;
}

Not this

h1 {
  font-weight: bold;
}
a {
  text-decoration: underline;
}

The code in the second example only restates the browser defaults; you’ve essentially written six lines of useless CSS.

Don’t write CSS in such a way that you’re immediately overwriting it

Do this

li {
  display: inline-block;
}
li + li {
  margin-left: 14px;
}

Not this

li {
  display: inline-block;
  margin-left: 14px;
}
li:first-of-type {
  margin-left: 0;
}

In the first example, li + li uses the sibling selector (the plus + sign) to select every li that is immediately preceded by an li and adds a margin to space them out.

The second example adds the margin to all li elements only to then remove it from the very first one (using the :first-of-type pseudo-class).

Use color values logically and consistently

Do this

p {
  background-color: hsla(62, 81%, 70%, 0.25);
  border: 3px solid hsl(62, 81%, 70%);
  color: white;
}

Not this

p {
  background-color: hsla(62, 81%, 70%, 0.25);
  border: 3px solid #ecf26c;
  color: rgb(255, 255, 255);
}

In the first example, the CSS keyword is used for white and otherwise HSL(a) colors are used; this makes it clear that the background and border colors have a relationship.

In the second example, that relationship is no longer obvious because the border color is expressed as a hex value. Additionally, the text color is expressed as an rgb value, which would be fine if the other colors in this example were also rgb(a), but instead it is just random and chaotic. 😵

This example does not mean that using HSL(a) values is a best practice, though I do find them to be easier to understand and modify than the other color values. It’s fine to use hex values if you’re not messing around with opacity of colors and either RGB(a) or HSL(a) if you are.

In general, CSS keywords should be avoided except for black or white. You’ll see that I use them often in demos because they’re simple to use and easy to understand, but they are very limiting to use in real world projects.

Avoid using units on measurements of zero

Do this

div {
  margin: 0;
  padding: 0;
  width: 0;
}

Not this

div {
  margin: 0px;
  padding: 0px;
  width: 0px;
}

There is no logical difference between 0 and 0px or 0%, so you can just skip using units on zero measurements.