Engineering Best Practices
Search…
Introduction
Tools
Languages
CSS
Markup
JavaScript
PHP
Workflows
Structure
Migrations
Powered By GitBook
CSS

Philosophy

We value content and the experience users will have reading it. We write CSS with this in mind and don't sacrifice our clients' most important assets over the latest, shiniest, half-supported CSS features just for the sake of using them. CSS should help enhance content, not bury it under "cool" distractions.
Our websites are built mobile first, using performant CSS. Well-structured CSS yields maintainability and better collaboration which ultimately yields better client experiences.

Syntax and Formatting

Syntax and formatting are keys to a maintainable project. By keeping our code style consistent, we not only help ourselves debug faster but we're also lessening the burden on those who will have to maintain our code (maybe ourselves too!)

Follow WordPress Standards

WordPress Core has coding standards for CSS. These should be followed for consistency across projects.

Architecture

It's preferred to follow the ITCSS Architecture. There's also a short introductory course on Skillshare.

CSS Syntax

CSS syntax is not strict and will accept a lot of variations, but for the sake of legibility and fast debugging, we follow basic code styles:
  • Write one selector per line
  • Write one declaration per line
  • Closing braces should be on a new line
Avoid:
.class-1, .class-2,
.class-3 {
width: 10px; height: 20px;
color: red; background-color: blue; }
Prefer:
.class-1,
.class-2,
.class-3 {
width: 10px;
height: 20px;
color: red;
background-color: blue;
}
  • Include one space before the opening brace
  • Include one space before the value
  • Include one space after each comma-separated values
Avoid:
.class-1,.class-2{
width:10px;
box-shadow:0 1px 5px #000,1px 2px 5px #ccc;
}
Prefer:
.class-1,
.class-2 {
width: 10px;
box-shadow: 0 1px 5px #000, 1px 2px 5px #ccc;
}
  • Try to use lowercase for all values, except for font names
  • Zero values don't need units
  • End all declarations with a semi-colon, even the last one, to avoid errors
  • Use double quotes instead of single quotes
Avoid:
section {
background-color: #FFFFFF;
font-family: 'Times New Roman', serif;
margin: 0px
}
Prefer:
section {
background-color: #fff;
font-family: "Times New Roman", serif;
margin: 0;
}
If you don't need to set all the values, don't use shorthand notation.
Avoid:
.header-background {
background: blue;
margin: 0 0 0 10px;
}
Prefer:
.header-background {
background-color: blue;
margin-left: 10px;
}

Declaration ordering

Declarations should be ordered alphabetically or by type (Positioning, Box model, Typography, Visual). Whichever order is chosen, it should be consistent across all files in the project.
If you're using Sass, use this ordering:
  1. 1.
    @extend
  2. 2.
    Regular styles (allows overriding extended styles)
  3. 3.
    @include (to visually separate mixins and placeholders) and media queries
  4. 4.
    Nested selectors

Nesting

Nesting has changed the lives of many, but like everything in life, abusing good things will ultimately be bad. Nesting makes the code more difficult to read and can create confusion. Too much nesting also adds unnecessary specificity, forcing us to add the same or greater specificity in overrides. We want to avoid selector nesting and over-specificity as much as possible.
If you're using PostCSS or Sass nesting is required in the following cases, because it will make the code easier to read:
  • pseudo-classes
  • pseudo-elements
  • component states
  • media queries

Selector Naming

Selectors should be lowercase, and words should be separated with hyphens. Please avoid camelcase, but underscores are acceptable if they’re being used for BEM or another syntax pattern that requires them. The naming of selectors should be consistent and describe the functional purpose of the styles they’re applying.
Avoid:
.btnRed {
background-color: red;
}
Prefer:
.btn-warning {
background-color: red;
}
For components that could possibly conflict with plugins or third-party libraries, use vendor prefixes. Don’t use names that can be blocked by adblockers (e.g. “advertisement”). When in doubt, you can check a class name against this list to see if it's likely to be blocked.

Documentation

Code documentation serves two purposes: it makes maintenance easier and it makes us stop and think about our code. If the explanation is too complex, maybe the code is overly complex too. Documenting helps keep our code simple and maintainable.

Commenting

We follow WordPress official commenting standards. Do not hesitate to be very verbose with your comments, especially when documenting a tricky part of your CSS. Use comment blocks to separate the different sections of a partial, and/or to describe what styles the partial covers:
/**
* Section title
*
* Description of section
*/
For single selectors or inline comments, use this syntax:
/* Inline comment */
Make sure to comment any complex selector or rule you write. For example:
/* Select list item 4 to 8, included */
li:nth-child(n+4):nth-child(-n+8) {
color: red;
}

Performance

Let's be honest, CSS "speed" and performance is not as important as PHP or JavaScript performance. However, this doesn't mean we should ignore it. A sum of small improvements equals better experience for the user.
Three areas of concern are network requests, CSS specificity, and animation performance.
Performance best practices are not only for the browser experience, but for code maintenance as well.

Network Requests

  • Limit the number of requests by concatenating CSS files and encoding sprites and font files to the CSS file.
  • Minify stylesheets
  • Use GZIP compression when possible Automate these tasks with a PHP or/and JavaScript build process.

CSS Specificity

Stylesheets should go from less specific rules to highly specific rules. We want our selectors specific enough so that we don't rely on code order, but not too specific so that they can be easily overridden.
For that purpose, classes are our preferred selectors: pretty low specificity but high reusability.
Avoid using !important whenever you can.
Avoid:
div div header#header div ul.nav-menu li a.black-background {
background: radial-gradient(ellipse at center, #a90329 0%,#8f0222 44%,#6d0019 100%);
}

Inheritance

Fortunately, many CSS properties can be inherited from the parent. Take advantage of inheritance to avoid bloating your stylesheet but keep specificity in mind.
Avoid:
.sibling-1 {
font-family: Arial, sans-serif;
}
.sibling-2 {
font-family: Arial, sans-serif;
}
Prefer:
.parent {
font-family: Arial, sans-serif;
}

Reusable code

Styles that can be shared, should be shared (aka DRY, Don’t Repeat Yourself). This will make our stylesheets less bloated and prevent the browser from doing the same calculations several times. Make good use of Sass placeholders.

CSS over assets

Don't add an extra asset if a design element can be translated in the browser using CSS only. We value graceful degradation over additional HTTP requests.
Very common examples include gradients and triangles.

Animations

It's a common belief that CSS animations are more performant than JavaScript animations. A few articles aimed to set the record straight (linked below).
  • If you're only animating simple state changes and need good mobile support, go for CSS (most cases).
  • If you need more complex animations, use a JavaScript animation framework or requestAnimationFrame.
Limit your CSS animations to 3D transforms (translate, rotate, scale) and opacity, as those are aided by the GPU and thus smoother. Note that too much reliance on the GPU can also overload it.
Avoid:
#menu li{
left: 0;
transition: all 1s ease-in-out;
}
#menu li:hover {
left: 10px
}
Always test animations on a real mobile device loading real assets, to ensure the limited memory environment doesn't tank the site.
Articles worth reading:

Accessibility

Animation

Not every animation brings pleasure to the end user. In some cases motion can trigger harmful reactions from users with vestibular disorders, epilepsy or even migraines.
The prefer-reduced-motion CSS media feature does not currently have the widest support, but is active in Safari and Firefox). However, we still recommend applying it, as it is simple to implement and affords a better experience for those using supported browsers.
Here is an example:
.animation {
animation: vibrate 0.3s linear infinite both;
}
​
@media (prefers-reduced-motion: reduce) {
.animation {
animation: none;
}
}

Responsive websites

We build our websites mobile first. We do not rely on JavaScript libraries such as respond.js as it does not work well in certain environments. Instead, we leverage a natural, mobile-first build process and allow sites gracefully degrade.

Min-width media queries

A responsive website should be built with min-width media queries. This approach means that our media queries are consistent, readable and minimize selector overrides.
  • For most selectors, properties will be added at later breakpoints. This way we can reduce the usage of overrides and resets.
  • It targets the least capable browsers first which is philosophically in line with mobile first — a concept we often embrace for our sites
  • When media queries consistently "point" in the same direction, it makes it easier to understand and maintain stylesheets.
Avoid mixing min-width and max-width media queries.

Breakpoints

Working with build tools that utilize Sass or PostCSS processing, we can take advantages of reusability and avoid having an unmaintainable number of breakpoints. Using variables and reusable code blocks we can lighten the CSS load and ease maintainability.

Media queries placement

In your stylesheet files, nest the media query within the component it modifies. Do not create size-based partials (e.g. _1024px.(s)css, _480px.(s)css): it will be frustrating to hunt for a specific selector through all the files when we have to maintain the project. Putting the media query inside the component will allow developers to immediately see all the different styles applied to an element.
Avoid:
@media only screen and (min-width: 1024px) {
@import "responsive/1024up";
}
.some-class {
color: red;
}
.some-other-class {
color: orange;
}
@media only screen and (min-width: 1024px) {
.some-class {
color: blue;
}
}
Prefer:
.some-class {
color: red;
@media only screen and (min-width: 1024px) {
color: blue;
}
}
.some-other-class {
color: orange;
}

Frameworks

Grids

Our preference is not to use a 3rd party grid system, use your best judgement and keep them simple! All too often we are faced with a design that isn’t built on a grid or purposefully breaks a loosely defined grid. Even if the designer had a grid in mind, there are often needs that require more creative solutions. For example: fixed-width content areas to accommodate advertising.
Sometimes a more complex grid system is warranted and leveraging a 3rd party library will gain some efficiency. However, keep in mind that by adopting a grid system you are forcing all future collaborators on the project to learn this system.

Resets

​Normalize.css is our primary tool for CSS resets.

Further reading

Previous
Languages
Next
Markup
Last modified 9mo ago
Copy link
Outline
Philosophy
Syntax and Formatting
Follow WordPress Standards
Architecture
CSS Syntax
Declaration ordering
Nesting
Selector Naming
Documentation
Commenting
Performance
Network Requests
CSS Specificity
Inheritance
Reusable code
CSS over assets
Animations
Accessibility
Animation
Responsive websites
Min-width media queries
Breakpoints
Media queries placement
Frameworks
Grids
Resets
Further reading