The 16 Unix Rules of CSS
I love the Unix philosophy. It places importance on the creation of small, useful programs that can work well on their own or together with other programs. The philosophy also makes clear that these modular programs should be easy to use and repurpose by developers other than their creators.
As someone who uses a small but valuable set of Unix tools on a regular basis (shoutout to ls, less, grep, and of course vi), it’s probably no surprise that I try to channel the Unix way of thinking in many different areas of development.
Like CSS, for example. You might already know how much I love writing small, single-purpose classes in CSS, which, like ideal Unix programs, can work well on their own or in a larger composition of other classes.
So here’s some food for thought. What follows is Eric Raymond’s 17 Unix Rules, lightly reworked for the context of writing CSS. I think it provides a really interesting way to think about writing CSS classes and styling the web. Maybe you will, too.
NB: I removed one of Raymond’s rules, ‘The Rule of Silence’, which has to do with a program’s generated output; this was too much of a stretch for CSS. This is why this isn’t ‘The 17 Unix Rules for CSS’, but rather ‘The 16’. I’ve also un-Americanised the spelling. Sorry, US friends.
@import ‘unix_philosophy’;
Rule of Modularity
Developers should build UI components out of simple classes, so problems are local, and parts of the component can be refactored in future versions to support new features. This rule aims to save time on debugging CSS.
Rule of Clarity
Developers should write CSS classes as if the most important communication is to the developer. This may be themselves, or other developers. This rule aims to make CSS readable and comprehensible for whoever works on the CSS in future.
Rule of Composition
Developers should write CSS classes that won’t conflict with other classes. This rule aims to allow developers to break down components into small, simple classes rather than complex monolithic classes.
Rule of Separation
Developers should separate the classes of UI components from the visual design of the components; one method is to use consistent component-driven visual design and atomic CSS development. This rule aims to let components be changed without rewriting CSS and consequently reduce the number of bugs.
Rule of Simplicity
Developers should design for simplicity by looking for ways to break up UI components into small, straightforward cooperating CSS classes. This rule aims to discourage developers writing classes that tie unrelated properties together (for example, float and background-color).
Rule of Parsimony
Developers should avoid writing multifaceted CSS classes. This rule aims to prevent time spent creating classes that are less feasible to reuse. Single-purpose classes are not only easier to optimise and maintain, they are also easier to delete when deprecated.
Rule of Transparency
Developers should design for visibility and discoverability by creating classes whose names and effects are easy to discern and internalise. This rule aims to encourage reuse and reduce debugging time.
Rule of Robustness
Developers should design robust CSS classes by designing for transparency and discoverability. Classes that are easy to understand are easier to stress test for unexpected conditions that may not be foreseeable in complex classes. This rule aims to help developers build reliable UI components and websites.
Rule of Representation
Developers should choose to make markup more verbose rather than the CSS classes of the UI component when faced with the choice. It is easier to understand concrete representations of a component (the markup) compared to complex CSS rulesets. This rule aims to make CSS behaviour clearer for any developer working on the project.
Rule of Least Surprise
Developers should design CSS classes that build on top of the potential users’ expected knowledge. For example, .red in a UI component should always mean ‘this text is red’. This rule aims to encourage developers to build classes that are free from side-effects.
Rule of Repair
Developers should design CSS classes that cause a component to fail in a manner that is easy to understand. In particular, classes should not have to compete on specificity. This rule aims to reduce time spent diagnosing inconsistency between a component’s declaration and its rendering.
Rule of Economy
Developers should value the user’s time over the developer’s time, because time (and data) consumed online is expensive for many users. This rule aims to reduce the cost of time and money spent by users on your product.
Rule of Generation
Developers should avoid writing new CSS and instead use a core set of CSS classes that have already been written. This rule aims to reduce human errors and save time.
Rule of Optimisation
Developers should prototype their CSS library before polishing it. This rule aims to prevent developers from spending too much time for marginal gains.
Rule of Diversity
Developers should design their CSS to be flexible and open. This rule aims to make CSS libraries flexible, allowing them to be used in new and interesting ways.
Rule of Extensibility
Developers should design for the future by making their CSS extensible, allowing for easy customisations without modification to the CSS’s architecture by other developers. This rule aims to extend the lifespan and enhance the utility of the code the developer writes.
Thank you @mrmrs_ for the top-notch editing assistance.