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:
It might be CSS that simply has a large file size. There's a lot of CSS output and so making changes to that codebase can be difficult, as there is so much of the code to consider.
The CSS could be said to be large due to the complexity of the user interface that is being built with it. The overall file size may be smaller than the first situation but there may be a great many pieces of user interface that's codified in those styles. Considering how to effect changes across all of those visuals may be problematic.
It might be large CSS simply due to the number of developers that have, are, and will be likely to touch and change the CSS codebase.
Or, it can be all the above.
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:
To allow the easy maintenance of a large CSS codebase over time
To allow portions of CSS code to be removed from the codebase without effecting the remaining styles
To make it possible to rapidly iterate on any new designs
Changing the properties and values that applied to one visual element should not unintentionally effect others
Any solution should require minimal tooling and workflow changes to implement
Where possible, W3C standards such as ARIA should be used to communicate state change within the user interface
In the next chapter we are going to look more specifically at these problems. However, first, an important cautionary note.
I believe in Pin Cing Do, which translates roughly as the The way of pragmatic coding (https://benfrain.com/be-better-front-end-developer-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:
ECSS won't give you the smallest possible CSS footprint (consider Atomic CSS (http://acss.io/) for that).
It isn't widely used and documented (consider BEM (https://en.bem.info/) if ubiquity is a major concern).
ECSS does not abstract styles and allow styling of elements from a bunch of specific utility classes. You should look at OOCSS and read the writing of its many advocates for that.
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 scaling and architecting CSS for large scale projects: specificity, the cascade, isolation and selectors tied to structural elements.