Writing scalable and manageable CSS

#Introduction

I've put together a few pieces of guidelines that PDT should use in order to attain a scalable and manageable CSS.

###Formatting & Syntax

We should be keeping consistency throughout by using the following: 
* four (4) space indents, no tabs
* maximum 80 character wide columns
* multi-line CSS

###When to split css into files

If you are building a new feature always split your CSS into its own SCSS file, if you're adding on top of a current feature or core think about the impact your code has and whether you think it should be separated out. Remember it all gets concatenated during a build step.

###Why 80 characters wide

It's simple: 
* you can have multiple files open side by side
* viewing CSS on sites like GitHub

###Multi-line CSS

There are a few reasons as to why you should write your CSS in multiple lines:

* you reduce the chance of merge conflicts
* More ‘truthful’ and reliable diffs.

All because each line carries it's own piece of functionality and/or change.

    .block {
        display: inline-block;
        width:  16px;
        height: 16px;
    }

###Indenting

When writing in SASS we should adhere to the same four 4 spaces like we do in JavaScript and we also should be leaving a blank line before and after.

    .foo {
        width: 160px;

        .bar {
            width: 200px;
        }

    }

###HTML

Always quote attributes, this reduces the chance of accidents, and is a more familiar format.

    <div class="foo">

Multiple values in an attribute should be separated by a space.

    <div class="foo bar">


###Naming Conventions

A good naming convention will tell you and your team

* what type of thing your class does
* where your class can be used
* what a class might be related to.

###BEM

BEM meaning Block, Element, Modifier - splits components classes into three groups:

* Block: The sole root of the component.
* Element: A component part of the Block.
* Modifier: A variant or extension of the Block.

For example:

    .person {}
    .person__head {}
    .person--tall {}

Elements are delimited with two 2 underscores `__`, and Modifiers are delimited by two 2 hyphens `--`.

In the above we can clearly see that `.person {}` is the Block and root of the enityt.
`.person__head {}` is an Element and is a smaller part of the `.person {}` Block.
Finally, `.person--tall {}` is a Modifier - it is a specific variant of the `.person {}` Block.


###BEM Context Example

Using the naming conventions in the previous example, we would write and nest our CSS like so. You are able to see that `.person--tall` is a direct Modifier of `.person` Block.

    .person {}

        .person__head {}

    .person--tall {}

But what if we want to modify an element.

    .person__eye--blue {}

Here we can see we’re directly modifying the eye Element. But using this method can lead to errors or losing control of your code base.

Imagine we have a `.car` Block; with a '.wheel` Element and its `.shiney` we could write it like so;

    .car__wheel--shiney {}

or by using descendant selector;

    .car--shiney .car__wheel {}

How would we write this descendant selector using Sass?

    .car {
      color: blue;
    }

        .car_wheel {
          color: black;
          
            .car--shiney & {
              color: silver;
            }

        }

    .car--shiney {
      display: block;
    }

[view on sassmeister](http://sassmeister.com/gist/71443762a42b915fe8e9)


###CSS Selectors

It is important when writing CSS, that we scope our selectors correctly.

For example, if we wanted to style our navigation menu: 

    header ul {}

This selector’s intent is to style any `ul` inside any `header` element, not what we intended.

A better solution would be 

    .site-nav {}

Poor Selector Intent is one of the biggest reasons for problems on any type of build.

###Location based styling

We should style things based on where they are, but on what they are.

    .sidebar a {}

This example will style any link inside of our `.sidebar`, this means that this style cannot be reused outside of `.sidebar`.

A better solution would be:

    .btn {}

This class allows us to use it outside of `.sidebar` and it doesn't rely upon any dependencies.



// Still more to write //