Styling Your CSS

Often CSS code is a mess. Here are my methods for creating clean, comprehensible, OCD-inspired CSS.


Indentation & Section Clustering

As your HTML is indented (hopefully), so you should indent your CSS. This conveys to you and other readers of your code the inter-dependencies in your CSS.

Listing related styles together like this also places all the styles for a particular part of your HTML in one part of your CSS document, allowing for easy revision of all styles for that part of your webpage. This is something I call section clustering.

I must note that the use of indentation in CSS is entirely optional and is something I use purely for readability — no functionality in CSS is dependent on indentation. For my braces I use Allman Style as this throws more whitespace into my CSS code and helps me, personally, read over my code more easily. The conventional use of braces in CSS, where the braces are on the same line as the selector, is Kernal Normal Form. Huge shout-out to the knowledgeable Terry Mun for highlighting these things!

Separating Layout & Font Styles

Drawing a literal line in your CSS code to distinguish layout and font styles for a particular section can condense related styles to a smaller section of your CSS document and allow for a speedier review of your code. How far you want to take this is entirely up to you — personally I find it beneficial to place all my font styles within a separte CSS file and apply standard styles with the use of classes within the HTML.

Note also the use of Section Clustering with indentation.

A word of caution relevant to mobile first design — putting your CSS in another file can increase page load times by requiring additional HTTP requests to fully load the page. This is only really a quantifiably problematic issue when dealing with 50+ extra HTTP request. You can address this issue by putting all CSS in one external file or even keeping it inline or embedded.

Selector Naming Conventions

Often I see CSS selectors (ids and classes) containing hyphens (i.e. -). Each to their own, personally I use the more programming-esque convention of camelCase for naming my CSS selectors. For example, I use:

id=“contentWrap” or class=“redFont boldStyle”

I don’t use:

id=“content-wrap” or class=“red-font bold-style”

My primary reason for using camelCase is that it is hyphen-less. This allows me to simply double left-click on a custom selector to select all of it as opposed to clicking and dragging to select all of it, contrast shown below:

Contrast of double-click highlighting results. Maybe I’m just lazy.

Another reason I use camelCase is I use a lot of JavaScript in web development and universally using camelCase creates code that’s more readable to me. I’ve heard others say they like to use difference naming conventions for JavaScript & CSS because they enjoy the contrast between the languages.

Ultimately, it doesn’t really matter what naming convention you use — that is entirely your choice. What is important is that you keep it consistent. You shouldn’t be using lots of different ways to name your CSS selectors within the one project, it’s just confusing and generally a bad practice as a coder. Don’t do this:

Organising Your Rules

Again, for easy review of my code, I’ve found it best to organise the order I list rules within a style reference. While it depends on the element and how I’ve separated particular styles already (see Separating Layout & Font Styles above), I list my rules in the following order:

  1. Rules influencing the position of the element;
  2. Rules influencing the position of the content within the element;
  3. Rules influencing the style of the element, and lastly;
  4. Rules influencing the style of the content within the element.

What Does All this Mean?

If you take anything from this please let it be the thought of simply organising your CSS. All I’ve mentioned is simply how I go about making my several-thousand-line CSS documents easier to manage for me; take what you will and use it as you wish. Just remember, idly throwing extra rules in here and there doesn’t help your clients, your colleagues, or yourself and makes your code much harder to review by anyone else. Save your time and the time of others by styling your CSS.

Email me when Tim Grillmeier publishes or recommends stories