In the last chapter we considered existing CSS methodologies, and where, for your humble authors needs, they fell short.
I'm not about to try and convince you that the Enduring CSS approach is the Alpha and the Omega. However, it does have different strengths and aims than the existing approaches. Therefore, even if taking it wholesale doesn't appeal, I'd hope there may be something you can borrow to solve your own issues.
Highlights of ECSS:
- It gains maintainability by isolating each visual pattern
- File size remains minimal over long periods of time by virtue of the fact that you can cut out sections/features/components with impunity
- Rules are self-quarantining
- Class names/selectors can communicate context, originating logic and variation
- All rules, their effects and reach are entirely predictable
When I first wrote about Enduring CSS I was expecting a backlash of sorts. At that time (August 2014), no-one was really advocating what I was suggesting. Received wisdom for scaling CSS was to abstract visual patterns, normalise designs as much as possible and DRY out code. Enduring CSS is, in some ways, the antithesis of these beliefs.
In this chapter, we won't be dealing with the specific technical detail of ECSS, such as naming conventions, tooling, authoring and organisation. We'll be covering those subjects in detail in future chapters. Instead, we will be looking at the broad aims and benefits of the approach as it compares to other approaches.
Before we get into this, I think it may help to clarify the terminology that will be used. The terms used to define the visual parts of a page are known by different names in different approaches. There's nothing revelatory in what I'm suggesting or the terms I'm using, it's just important we're all on the same page before we get into this.
I'm using the term module to designate an area of functionality and/or the code that creates it. To exemplify, the header of a website could be considered a module. The header module would, in turn, be made up of other smaller pieces of functionality. For example, drop-down menus or search boxes. These nested pieces of functionality would be defined as components. Finally, our smallest items would be the child nodes that make up a component or module.
So, to reiterate:
- A module is the widest, visually identifiable, individual section of functionality
- Components are the nested pieces of functionality that are included within a module
- Child nodes are the individual parts that go to make up a component (typically nodes in the DOM)
For brevity, for what follows, when I'm referring to modules, it could be a module or component. The difference from a ECSS authoring perspective is unimportant.