:for each declaration.
rect()values. This helps differentiate multiple color values (comma, no space) from multiple property values (comma with space).
blackinstead of their hex counterparts:
#000. For all other colors, use hex codes rather than color names.
input[type='text']. They’re only optional in some cases, and it’s a good practice for consistency.
margin: 0;instead of
') rather than double quotes (
") in attribute selectors and properties. Do not use quotes in URI properties (
url()). Exception: the
@charsetrule requires double quotation marks.
Questions on the terms used here? See the syntax section of the Cascading Style Sheets article on Wikipedia.
Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.
Be sure to write in complete sentences for larger comments and succinct phrases for general notes.
.btnis recognizable as button, but
.sdoesn't mean anything.
.js-*to indicate an element as a target of behavior (as opposed to style). More often than not they're just doubling up on something that already has a meaningful name and only serve to make your code harder to read.
These rules also apply when creating Sass and Less variable names.
Related property declarations should be grouped together following the order:
Layout and positioning come first because they can remove an element from the normal flow of the document and override box model related styles. The box model comes next as it dictates a component's dimensions and placement.
Everything else takes place inside the component or without impacting the previous two sections, and thus they come last.
For a complete list of properties and their order, please see my stylelint-order† config.
† stylelint-order is a plugin to the popular style linter stylelint, that enables you to check the order of your style declarations.
Use white space (newlines) to enhance readability:
@import is slower, adds extra page requests, and can cause other unforeseen problems. Avoid them and instead opt for an alternate approach:
@importis okay in this case)
For more information, read this article by Steve Souders.
!important. I MEAN IT.
!important: when you need to override a style and you don't have access to the stylesheet in which it is defined, and therefore no inkling as to its specificity.
!important. It's an admission of failure, as well as the opening shot in a (thermonuclear) war of specificity against yourself.
In short, don't do it.
Place media queries as close to their relevant rule sets whenever possible. Don't bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future. Here's a typical setup.
Don't use vendor prefixes in your CSS:
Instead, write your code without vendor prefixes and use a plugin like autoprefixer in your build pipeline.
In instances where a rule set includes only one declaration, keep the line breaks for better readability; your declarations will begin in the same column and be easier to scan.
Strive to limit use of shorthand declarations to instances where you must explicitly set all the available values. Commonly overused shorthand properties include:
Oftentimes we don't need to set all the values a shorthand property represents. For example, HTML headings only set top and bottom margin, so when necessary, only override those two values. Excessive use of shorthand properties often leads to sloppier code with unnecessary overrides and unintended side effects.
That said, there is no denying that using shorthand properties is convenient. The rule here is to use judgement and avoid overzealously using shorthand properties, especially if you know you'll need to override them in part later.
The Mozilla Developer Network has a great article on shorthand properties for those unfamiliar with notation and behavior.
[class^='…']) on commonly occurring components. Browser performance is known to be impacted by these.
Avoid unnecessary nesting. Just because you can nest doesn't mean you should. Consider nesting only if you must scope styles to a parent and if there are multiple elements to be nested. The consequence is needlessly long, less performant, overly specific selectors.
Also take care with
&, the parent selector:
&(placing it at the end of a nested selector). It's confusing as hell and often has unintended consequences.
For improved readability, wrap all math operations in parentheses with a single space between values, variables, and operators. Take special care to do this for shorthand properties.
Don't ever use raw hex colors in Less and Sass. Define them with human-readable variable names and use those. Better yet, assign colors to variables indicating their semantic usage.
Using semantic color variables throughout your code is more readable and easier to change.
An example file hierarchy: