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 was, by necessity, densely populated with visual components; sliders, buttons, input fields etc.

In addition, consider that this interface was (and is) constantly evolving and needed to be changed rapidly. Furthermore, any changes might be made by any number of different style sheet authors.

Without a clearly defined CSS writing methodology, through the many iterations, the CSS was always out of hand. The style sheets were in a perpetual state of entropy as a result of mixed approaches, different levels of technical understanding between authors and code documentation that varied greatly in quality.

So the result was CSS that was difficult to iterate upon, hard to reason about and nobody was ever quite sure where redundancy lay. Worse still, style sheet authors lacked 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 some of what I'm describing will sound familiar.

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.