- Thou shalt have a single source of truth for all key selectors
- Thou shalt not nest, unless thou art nesting media queries or overrides
- Thou shalt not use ID selectors, even if thou thinkest thou hast to
- Thou shalt not write vendor prefixes in the authoring style sheets
- Thou shalt use variables for sizing, colours and z-index
- Thou shalt always write rules mobile first (avoid max-width)
- Use mixins sparingly, and avoid @extend
- Thou shalt comment all magic numbers and browser hacks
- Thou shalt not inline images
- Thou shalt not write complicated CSS when simple CSS will work just as well
Blessed are those that follow these rules for they shall inherit sane style sheets.
Amen.
The following, highly opinionated, set of rules came about as a way to author predictable style sheets across teams of developers. Each rule can be enforced with tooling. When there is just one CSS developer on a project, spending time developing or integrating tooling may seem superfluous. However, beyond a couple of active developers the tooling will earn its time investment time and again. We will deal with the tooling to police the rules in the next chapter. For now, let's consider the syntax and the rules themselves.
To achieve more maintainable style sheets we can lean upon PostCSS, a piece of CSS tooling that allows the manipulation of CSS with JavaScript. The curious can look here for more information: https://github.com/postcss/postcss
PostCSS facilitates the use of an extended CSS syntax. For the purpose of authoring, the syntax used borrows heavily from Sass (http://sass-lang.com/). This provides functionality to make our authoring style sheets easier to maintain.
Using PostCSS we are able to make use of:
- Variables
- Mixins (like macros for certain settings such as font-families)
- Referencing a key-selector with an ampersand symbol (
&)
Practically, PostCSS can enable similar functionality to a CSS pre-processor such as Sass, LESS or Stylus.
Where it differs is in its modularity and extensibility. Rather than swallow the whole pill as is needed with the aforementioned pre-processors, using PostCSS allows us to be more selective about the feature set we employ. It also allows us to easily extend our feature set at will, either with any number of off the peg plugins, or, by writing our own plugins with JavaScript.
For example, where Sass allows loops to be written, we choose to prevent that capability. For instance where looping is needed to solve a specific problem (for example, 100 variants of different coloured headers) we can still achieve that buy as a PostCSS plugin written in JavaScript.
In addition, thanks to the PostCSS ecosystem, we can perform static analysis of the authoring styles with linting; failing builds and code commits when undesirable code is authored.
Note
In case the term linting is alien to you, it's another term for static analysis. It looks at the authored code and makes suggestions based on any number of pre-defined rules. For example, it might issue a warning if you use floats, or don't put white-space or a semi-colon where required. Generally speaking, you can use linters to enforce any kind of coding conventions you like and while more than useful when working alone, they can be priceless when working in teams: where many (careless) hands might touch the code.
When we are authoring ECSS, we want to avoid producing CSS that suffers from being overly specific, littered with unneeded prefixes, poorly commented and full of magic numbers.
The following 10 rules set-out what are considered to be the most important rules to achieve this goal.
- Override: A situation where the values of a key selector are purposely amended based upon inheritance
- Key selector: The right most selector in any CSS rule
- Prefixes: Vendor specific prefixes e.g.
-webkit-transform: - Authoring style sheets: The files we author the styling rules in
- CSS: The resultant CSS file generated by the tooling and ultimately consumed by the browser
Let's now consider each rule and the problem it aims to solve.