If you are like most programmers, you don’t think of CSS as a programming language. It’s a description language, it describes the look of elements on a website. While developing your next super-cool web application you describe the visuals using CSS and it feels like you are writing a book instead of an application, losing sight of all the CSS as you keep developing.

If you have already written CSS you most probably have…

• … freaked out changing your existing CSS to new requirements, as you noticed the side-effects post-deploy.
• … wrote thousands of lines of CSS for the hundreds of different elements and states that need to be styled.
• … used a style="..." attribute for the quick fix. Why did the designer add that extra space only to one of the elements?!
• … used the most .complex>p[ossible^='selector']:nth-child(-n+5)>a:hover to describe your design.

What if CSS was a programming language?

Now step aside and treat CSS as if it was a real programming language. How do you write good code?

1. Write a test.
2. Write the code that makes it green.
3. Refactor code to not contain any WTFs.
4. Lather, rinse, repeat.

The TDD workflow can be leveraged to write CSS when developing a living style guide. This article explains what a living style guide is, why you should have one in your next project and some useful techniques to get started.

Use the following techniques to master CSS:

0. Use a framework

This should actually be a no-brainer. There are gazillions of CSS frameworks out there, choose one of the many and reuse its components in your project. Most frameworks have some way to customize components, so make sure you choose a framework that suits your workflow.

If you haven’t heard about CSS frameworks here are some links to get you started: Bootstrap, Zurb Foundation, Semantic UI, Pure CSS.

1. Write clean CSS with BEM

Forget fancy selectors. Keep it simple and use class selectors. Name your CSS classes according to the BEM documentation. If there is one thing you take away from the BEM methodology it’s the Block > Element > Modifier approach, hence BEM. If this is the first time you hear BEM, this article will definitely help get you started.

Lets take the following CSS class names of a simple image slider as an example:

.slider
.slider--play
.slider--pause
.slider__image
.slider__image--active
.slider__caption
.slider__button-prev
.slider__button-next

Now, can you tell me what the different CSS classes are used for? Could you write down the HTML markup of an image slider? Of course, there are variations, but the CSS classes provide a good sense of clarity when using components. According to the BEM approach we now have:

• Block: .slider is a block that is used to present an image slider.
• Element: Elements contribute to build a block: .slider__image is used to style an image in the slider. .slider__caption shows a caption for an image. .slider__button-* are used for switching to the previous/next image.
• Modifiers: Modifiers are used to express state in a block/element. .slider__image--active clearly denotes an image as the one which is currently visible to the user. Also, .slider--pause stops the autoplay function of the slider.

As you can see, it is very intuitive to describe a rather complex component with BEM naming conventions. Besides that, the BEM naming conventions also help you to properly namespace your selectors, such that you won’t run into selector interference problems.

2. Use a pre-processor with a proper build system

SCSS and LESS are popular CSS preprocessors that save you a lot of time. Your favorite CSS framework may even be available as a library for your preprocessor. Then you can customize, mix and match the functionality of your library and only use the parts of the framework you really need. Preprocessor languages usually contain additional libraries that contain useful functionality, such as Compass or Bourbon for SCSS.

If you do have a pre-processor, be sure to integrate it into your favorite IDE to auto-compile on source changes. Make it part of your continuous integration build process. Use a SCSS linter or LESS linter to automatically check your written styles for syntactical beauty. Also, make sure to integrate BrowserSync into your toolchain. BrowserSync reloads your web page when certain source files change. It saves you a ton of time in the long run. If you do not have a build system setup, check out Brunch.

3. Use a living styleguide

A living styleguide is a rendered documentation for your stylesheet. It is called a living styleguide, as the styleguide is built from the source code comments you write in your SCSS files. Of course, you’ll need a specific syntax for proper rendering. There are a couple of different approaches to generate a living styleguide. I use the Knyle Style Sheets (KSS) throughout my projects, as there are generators in PHP and node.js.

Simple Development

Developing a living styleguide makes developing the stylesheet of an application a breeze: you can immediately create documentation to see all possible states of the components you develop. You think about your markup and have a nice and clean playground to try things out. To properly build a style guide I highly recommend to read the introduction to the “Dropbox (S)CSS Style Guide”. The article contains a lot of great ideas you can also use in your style guide.

Easy Maintenance

Another benefit of using a living styleguide is the simple maintenance process. The application should in most cases use the markup the examples in the style guide define. If you need to change styles or modify existing components, you can immediately see the effects of your changes and possible backwards compatibility issues. If you need to break things, fine - due to the styleguide you know which markup needs to change. You are then able to safely carry the change through to your application. No more guessing and hoping when moving quickly.

4. Think in components

A living styleguide requires components. Bootstrap has become so popular because it offers easy-to-use and flexible components. You want that in your application, too! Of course, no one is able to perfectly design all components upfront. Be sure to think about what elements have common use cases and display properties and try to group them in a component. There is a popular example examining the media object on Facebook.

Interactive Components

Some of your components do not only contain the style, but also commonly used interaction patterns. For example, take a look at the “JavaScript” section in the Bootstrap documentation. If you are starting to think in components you can take the approach further by developing reusable JavaScript components which leverage your styles. There is a great article breaking down how to design a component to help you get started.

Kaizen:last-child

Last, but not least, be sure to always reflect your workflow and seek ways to improve upon. There are great resources out there covering a lot of topics. A very comprehensive guide is the css { guide: lines; } website by Harry Roberts.

If you have any questions, want more details on a certain topic or need any help, feel free to leave a comment below.