Frontend Style Guide

Since my very first days at Arcbees, I’ve been coached in code styling. I always had my own way of writing code, but never did so using strict rules. Following a pre-defined structure for my CSS, like writing properties in a specific order, was kind of annoying at first. I had to print the CSS property order and always refer to it, so my CSS stayed consistent with Arcbees’ styling conventions.

However, it only took a few days before I switched from resisting this practice to embracing it. The power of following a structured approach became clear, and I wanted more! ArcBees followed a very rich set of code styling conventions for Java files, but there were fewer conventions for writing CSS and HTML, except for the Rule of arrangement mentioned above. As a new convert believing strongly in the value of conventions, I began reading a lot about front-end best practices and style. The result of this research was ArcBees’ very own Frontend Style Guide.

What is it and what it does

A frontend style guide is a collection of guidelines to apply when writing CSS and HTML. One of its main purposes is to provide a common syntax and vocabulary for a project. Rules are created to ensure cohesion in the code, to ease maintainability and to construct a common and familiar structure for the team to work on.

The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you’re saying rather than on how you’re saying it.
– Google HTML/CSS Style Guide

When your company consistently follows one style guide, you can jump into the middle of a new project you did not help start, and soon become an active contributor. The new project will feel familiar enough to work on because it follows the same rules and structure as all your other projects.

Following a style guide will also make it much faster to find elements. You will not have to guess where a specific element is. With ordering rules, you will know at a glance if a specific type of property is present inside your CSS element or not.

What we did

We started by analyzing how we were coding most of the time, both to reveal patterns that we were repeating, and also to illuminate practices that changed from time to time. We then had a look at what people in other companies do, and why. We merged all of these observations together to create our own Frontend Style Guide.

Here’s is a quick overview of some guidelines we developed :


  • Soft tabs, 4 spaces
  • Nested elements should be indented
  • Only use lowercase on HTML element names, attributes and values (except for text)
  • Don’t add values on boolean attributes (disabled, selected, checked …) : <input disabled=”disabled” type=”text” />
  • Each page should have its own <title>

Read the complete HTML Style Guide.


  • Put spaces before { in rule declarations
  • Use shorthand hex values, when possible. Use #fff instead of #ffffff
  • Avoid specifying units for zero values. Use margin: 0; instead of margin: 0px;
  • Properties are grouped by categories :
    • Typography, color and background
    • Display
    • Positioning
    • Visual and animation
    • Others
    • Mixins
  • Avoid over-qualified selectors. Use .widget_link instead of a.widget_link
  • Class names should be human readable, communicating useful information. Use structural and purposeful names over presentational ones
  • Place media queries as close to their relevant rule sets whenever possible. Don’t bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future.

Read the complete CSS Style Guide.

Create your own

You should definitely create your own style guide, adapted to your needs, and try to stick to it as much as possible. Feel free to start from our Frontend Style Guide if you want a structure to play with. You should also check out other great style guidelines available online, such as the following :

Have fun coding!