How CSS organises carwow

I think he meant to say, ‘How carwow organizes CSS’

CSS is one of those technologies you love to hate. A day doesn’t go by where I feel both great about the functional interfaces we create here at carwow and self-loathing that I broke the style in an unrelated page.

The most difficult thing about CSS is structuring and organising it, in a way that is re-usable and maintainable. If you’ve been following the 8 o’clock news you’ve probably come across some new ideas around modularising CSS in React. As an idea it sounds interesting, removing the global nature of CSS could solve a lot of the problems we are dealing with as developers. Another similar idea is CSS Modules which is playing around with more or less the same concept. Are these ideas production ready or even good? I don’t know but it would be interesting to see what the future holds.

Until then, we try to get better at CSS and find ways to improve or refactor our existing code. We usually discuss these kind of things during our bi-weekly tech lunches. But there are so many directions and choices. Which one should you go with?

‘If you cannot organise the CSS, let the CSS organise you’ — Mr Robot

At carwow we have experimented with a couple of ideas and here are the three main we follow:

A styleguide

A styleguide is library of components and visual structures that are used throughout our apps. It allows for quick production ready pages that are proven to work without the need to compose them. You can literally copy/paste them into your source code. Kind of like Bootstrap or Foundation but specifically for your own app.

A styleguide has two main benefits: it allows consistency across pages with a single point of maintenance and loosely enforces a more structure approach to new designs. To make the latter point a bit more clear, it simply means that a new variation of a component is more thought through. Let’s look at an example: Bootstrap has a buttons components. They have different variations based on colour and size. If a developer decides all of a sudden to add a ghost button, they will have to think where it fits in the grand scheme of things. Is this a derivative of the standard button or is a progression where all the buttons will become like that?

In the future we will post more about how to create your own styleguide but for now you can have a look at carwow’s one.

BEM

BEM stands for Block-Element-Modifier. I’m not going to go in great length about BEM, you can read all about it here in this excellent article.

In simple terms, BEM is a naming framework for organising your CSS code. Let’s have a look at an example with the standard way of writing CSS.

<ul class="posts>
  <li class="post">
    I am <span class="big-text">Groot</span>
  </li>
</ul>

Simple enough! But you lose the context of how the CSS part of your structure is correlated. For example, if I remove the posts class, does it affect the structure?

Let’s see the same example with BEM

<ul class="posts>
  <li class="posts__post">
    I am <span class="big-text">Groot</span>
  </li>
</ul>

What kind of information this type of naming convey? It’s very clear that the element .posts__post is part of the .posts scope where as .big-text is not a dependency of the structure.

What I like about BEM is it promotes a hierarchy where the element belongs to a block rather than a parent-child relationship.

Partial the s**t out of your CSS

Reading through a single CSS file like show.scss is really difficult. And most importantly the rules do not follow the HTML structure; if you split your editor into the CSS and the HTML file, will the classes on the HTML be in order in your CSS file? Probably not. And it makes it really difficult to refactor because you have to rely now on the grep driven development. So since we use BEM which is a very good indicator as to how the page is split up, we started componentizing our everyday CSS as well. As an example instead of

/* index.scss */
.posts {}
.cars {}
.posts__post {}
.posts__headline {}
.cars__engine {}

We now have

/* index.scss */
@import 'the-relevant-posts-css';
@import 'the-relevant-cars-css;
/* the-relevant-posts-css.scss */
.posts {}
.posts__post {}
.posts__headline {}
/* the-relevant-cars-css */
.cars {}
.cars__engine {}

This makes it much easier to reason about where your CSS rules for a particular block of HTML are. It also makes it easier to move it into the styleguide if we decide to make it a shared component between our parts.

That’s all folks. If you try any of the above and it works for you, we’d love to know about it!

Interested in making an Impact? Join the carwow-team!
Feeling social? Connect with us on Twitter and LinkedIn :-)