CSS Style Guide
Last updated
Last updated
We encourage some combination of OOCSS and BEM for these reasons:
It helps create clear, strict relationships between CSS and HTML
It helps us create reusable, composable components
It allows for less nesting and lower specificity
It helps in building scalable stylesheets
OOCSS, or “Object Oriented CSS”, is an approach for writing CSS that encourages you to think about your stylesheets as a collection of “objects”: reusable, repeatable snippets that can be used independently throughout a website.
Nicole Sullivan's
Smashing Magazine's
BEM, or “Block-Element-Modifier”, is a naming convention for classes in HTML and CSS. It was originally developed by Yandex with large codebases and scalability in mind, and can serve as a solid set of guidelines for implementing OOCSS.
CSS Trick's
Harry Roberts'
We recommend a variant of BEM with PascalCased “blocks”, which works particularly well when combined with components (e.g. React). Underscores and dashes are still used for modifiers and children.
Example :
.ListingCard
is the “block” and represents the higher-level component
.ListingCard__title
is an “element” and represents a descendant of .ListingCard
that helps compose the block as a whole.
.ListingCard--featured
is a “modifier” and represents a different state or variation on the .ListingCard
block.
Use the .scss
syntax, never the original .sass
syntax
Order your regular CSS and @include
declarations logically (see below)
Property declarations
List all standard property declarations, anything that isn't an @include
or a nested selector.
@include
declarations
Grouping @include
s at the end makes it easier to read the entire selector.
Nested selectors
Nested selectors, if necessary, go last, and nothing goes after them. Add whitespace between your rule declarations and nested selectors, as well as between adjacent nested selectors. Apply the same guidelines as above to your nested selectors.
Prefer dash-cased variable names (e.g. $my-variable
) over camelCased or snake_cased variable names. It is acceptable to prefix variable names that are intended to be used only within the same file with an underscore (e.g. $_my-variable
).
Mixins should be used to DRY up your code, add clarity, or abstract complexity--in much the same way as well-named functions. Mixins that accept no arguments can be useful for this, but note that if you are not compressing your payload (e.g. gzip), this may contribute to unnecessary code duplication in the resulting styles.
@extend
should be avoided because it has unintuitive and potentially dangerous behavior, especially when used with nested selectors. Even extending top-level placeholder selectors can cause problems if the order of selectors ends up changing later (e.g. if they are in other files and the order the files are loaded shifts). Gzipping should handle most of the savings you would have gained by using @extend
, and you can DRY up your stylesheets nicely with mixins.
Do not nest selectors more than three levels deep!
When selectors become this long, you're likely writing CSS that is:
Strongly coupled to the HTML (fragile) —OR—
Overly specific (powerful) —OR—
Not reusable
Again: never nest ID selectors!
If you must use an ID selector in the first place (and you should really try not to), they should never be nested. If you find yourself doing this, you need to revisit your markup, or figure out why such strong specificity is needed. If you are writing well formed HTML and CSS, you should never need to do this.
Background url and content url writing. This is our way of dealing with changing domains from local to staging to live websites
Reference:
While it is possible to select elements by ID in CSS, it should generally be considered an anti-pattern. ID selectors introduce an unnecessarily high level of to your rule declarations, and they are not reusable.
For more on this subject, read on dealing with specificity.