CSS & SASS Standards

0. General rules
1. Formatting
2. Comments
3. OOCSS
4. Ordering of property declarations
5. Variables
6. Mixins
7. Extend directive

0. General rules

DON'T use "!important" unless you have no other option!

Avoid using "position: absolute;" as much as you can.

Avoid arbitrary percentages and magic numbers

Avoid custom @media queries

Avoid using position: absolute unless required, as this puts more pressure on you to ensure a consistent layout across screen sizes. It can also create issues when other elements are within the same container. If you must use position absolute, ensure it is inside a position: relative container, and that it behaves as expected when the screen is resized, and when extra content is added (multiple lines etc)

Avoid arbitrary percentages - prefer Bootstrap Grid classes

• Inconsistent percentages can lead to content moving out of alignment as the screen width is lowered. 
• It is also hard for other developers to read/fix, when compared to margin-left, padding, etc.

Use px for padding instead of % - this will ensure we stick to the guidelines of the design and can ensure padding etc throughout the different screen sizes. If we are all using Bootstrap classes, the entire site will "feel" the same. Percentages increase the risk that each component has a unique breakpoint and look and feel throughout screen widths It is easier to adjust Bootstrap classes or padding during Design review, than to adjust a % by 0.002

Ensure you test the following as you build:

• Change the width of your browser: Your CSS should look great across all screen sizes from 1600px down to 320px
• Add extra text: Your layout should not break with double the amount of content in it (Please see the Multi language extension)

Avoid float: left/right & display: inline-block unless required Both of these things have their quirks, and float may interfere with Bootstrap classes. Use a <span> tag instead of a <div> for inline-block. Use Bootstrap Grid classes and text-align first before going for float

1. Formatting

Use soft tabs (2 spaces) for indentation

Prefer dashes over camelCasing in class names.

Bad

.componentTopHeroPanel {
    // code here
}

.component_top_hero_panel {
    // code here
}

Good

.component--top-hero-panel {
  // code here
}

Do not use ID selectors.

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 specificity to your rule declarations, and they are not reusable.
For more details, please read CSS Wizardry's article

Bad

#btn-orange {
  //
}

Each selector on its own line

When using multiple selectors in a rule declaration, give each selector its own line.

Bad

.class-no, .class-not-good, .class-not-good-at-all {
    // ...
}

Good

.class-good, 
.class-one, 
.class-one-per-line {
    // ...
}

Spacing issues

• Put a space before the opening brace { in rule declarations
• In properties, put a space after, but not before, the : character.
• Put closing braces } of rule declarations on a new line
• Put blank lines between rule declarations

Bad

.bad-spacing-1{ // bad
  font-size :18px; // bad
  color: white;} // bad
.bad-spacing-2{ // bad
  font-size :18px; //bad
}

Good

.good-spacing-1 {
  font-size: 18px;
  color: white;
}

.good-spacing-2 {
  font-size: 18px;
}

2. Comments

• Prefer line comments (// in Sass-land) to block comments.
• Prefer comments on their own line. Avoid end-of-line comments.
• Write detailed comments for code that isn't self-documenting:
  • Uses of z-index
  • Compatibility or browser-specific hacks

3. OOCS

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.

• 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

Nicole Sullivan's OOCSS wiki

4. Ordering of property declarations

List all standard property declarations, anything that isn't an @include or a nested selector.

.btn-red {
  background: red;
  font-size: 20px;
  // ...
}

Grouping @includes at the end makes it easier to read the entire selector.

.btn-red {
  background: red;
  font-size: 20px;
  @include transition(all .3s ease);
}

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.

.btn-red {
  background: red;
  font-size: 20px;
  @include transition(all .3s ease);

  .arrow{
    padding-left: 10px;
  }
}

Do not nest selectors more than three levels deep!

.component--single-promo-panel {
  .container {
    .heading {
      // STOP!
    }
  }
}

When selectors become this long, you're likely writing CSS that is:

• Strongly coupled to the HTML (fragile)
• Overly specific (powerful)
• Not reusable

5. Variables

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).

Variables should be defined in a separate file, named _variables.scss. Then using the @import feature, we add this file into the master scss.

6. Mixins

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.

_mixins.scss

@mixin transition($transition) {
  -webkit-transition: $transition;
  -moz-transition: $transition;
  -o-transition: $transition;
  transition: $transition;
}

_styles.scss

.button{
  font-weight: bold;
  @include transition(background 0.3s ease);
}

7. Extend directive

@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.