Pitchtarget
Index
Colors
Components
Guidelines
Icons
Guidelines
General

Indent using 2 spaces
All filenames should be lowercased
Javascript

Naming Convention

d-a-s-h-e-s for file names, folder names, ember components
camelCase Javascript, JSON
Code convention

Varibles declaration with var: always
Declare one variable per var statement, it makes it easier to re-order the lines
Prefer ' over "
Always use semicolons ;
Always use parentheses (also for if statement of one line)
Prefer forEach over for loop
General advices

BE CONSISTENT. If you're editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around all their arithmetic operators, you should too. If their comments have little boxes of hash marks around them, make your comments have little boxes of hash marks around them too. The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you're saying rather than on how you're saying it. We present global style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.

CSS

General

app.less is used only for importing other styles
Do not use selectors based on Id
Avoid element selectors, prefer classes
// wrong
<div class="folder">
  <span>Folder Name</span>
</div>

/* The Folder Module */
.fld > span { ... }

// right
<div class="folder">
  <span class="folder--name">Folder Name</span>
  <span class="folder--items">(32 items)</span>
</div>

.fld--items { ... }
.fld--name { ... }
In less files avoid using deep nesting (more than 3 levels). Nest media queries
Avoid extending classes, use mixins instead. Extending a class leads to ugly output in term of css selectors.
Design Principles

Modules are entities that are aware of the context in which they are placed and can be used as standalone components. They are the reusable, modular parts of our design. Buttons, navs, dropdowns, forms, etc are great examples of components. Class name convention for module is .moduleName
Sub Modules are variations of a module in term of graphics, these variations are based on context, for example if we have a .btn class for rapresenting a button with 100px width and we want a button with 200px width we can create a submodule .btn-large that redefines the width property. Class name convention for sub-module is .module-subModule
Sub Components are necessarly placed inside a module and rappresent pieces of the module structure e.g
  .modal {}
  .modal-large {}
  .modal--header {}

  <div class="modal modal-large">
    <div class="modal--header">...</div>
    <div class="modal--body">...</div>
    <div class="modal--footer">...</div>
  </div>
Class name convention for sub-components is .module--subComponent
States are modifiers that describe how our modules will look when they are in a particular state. Generally speaking the difference between sub-modules and states is that the second one is used when the state depends on some javascript properties e.g:
  // Normally we have the 'btn' module
  <button class="btn">OK</button>

  // If some javascript can alter the state of the button and make it disabled
  // then we have to add the state btn-is-disabled
  <button class="btn btn-is-disabled">OK</button>
Class name convention for states is .module-is-state
Try to avoid conditional styling based on location. If you are changing the look of a module for usage elsewhere on the page or site, sub-class the module instead.
For state class (i.e when need to change appearance based on behavior) use something like: .tab-is-active where 'tab' is the name of the module or the name of the component.
Common situations

  <button class="btn">Cancel</button>

  <div class="modal modal-large">
    <div class="modal--header">...</div>
    <div class="modal--body">...</div>
    <div class="modal--footer">
      <button></button>
    </div>
  </div>