Chapter 1. Enduring CSS

Writing styles for rapidly changing, long-lived web projects

Introduction

This isn't actually a book about writing CSS, as in the stuff inside the curly braces. It's a book about the organising and architecture of CSS; the parts outside the braces. It's the considerations that can be happily ignored on smaller projects but actually become the most difficult part of writing CSS in larger projects.

Terms like 'CSS at scale', or 'Large-scale CSS' can seem quite nebulous. I'll try and clarify.

When people talk about 'large scale CSS' or 'writing CSS at scale' there can be a few possible metrics that relate to the 'large' or 'big' part of the description.

Or, it can be all the above.

Defining the problem

Enduring CSS was born from my own need to define a rational approach to writing CSS on large scale web applications.

The definition of what makes something a 'web application' as opposed to merely a 'web page' can be divisive so let's put that aside for now. Let's simply consider the scenario in which a new approach to writing CSS was needed.

Consider an interface that is, by necessity, densely populated with visual components; sliders, buttons, input fields etc.

In addition, consider that this interface is constantly evolving and needs to change rapidly. Furthermore, these changes are made by many different style sheet authors that need to touch the CSS code daily.

Due to the number of authors, through many iterations, the CSS becomes unruly. Typically this style sheet entropy is the result of mixed approaches, different levels of technical understanding between authors and code documentation that varies greatly in quality.

So we have CSS that is now difficult to iterate upon, hard to reason about and nobody is ever quite sure where redundancy lies. Ultimately style sheet authors lack the confidence to remove code for fear of inadvertently effecting other parts of the application.

If you've ever inherited or worked in a team on a large CSS codebase, I'm sure you can sympathise.

Therefore, at the outset of my journey, I defined some basic needs. More simply, these were the problems that any new CSS authoring approach had to solve. Here is the list of those needs:

In the next chapter we are going to look more specifically at these problems. However, first, an important cautionary note.

Solve your own problems

I believe in 'Pin Cing Do', which translates roughly as the 'The way of pragmatic coding'. This means solving the problems you actually have. Therefore, I'll state something up front that may be obvious to some:

It may be that the problems I had were not the problems you have. As such, you should temper the advice and approach offered herein accordingly. Alternatively, consider that your needs may be better addressed by different approaches and methodologies. I'm not going to try and convince you that ECSS is necessarily the best solution in all situations. For example:

OK, public service announcement out of the way. Let's head on to the next chapter. This is where we'll look at the principle problems of working with CSS on large scale projects: specificity, the cascade, isolation and selectors tied to structural elements.