Econsultancy new build: General SASS & CSS Rules

1. Principles

Principle 1: Classes as selectors, not ids or element tags.

CSS classes are best suited to keep the code modular, easy to change and has additional 
benefits, such as being able to mix styles together. If we've done a good job of building up 
our styles, it should be very fast to prototype and build out new layouts.

The main risk using classes as selectors is the possibility of conflicts if two different 
classes get the same name. This is where BEM comes in handy with prefixes and naming conventions 
descriptive enough to prevent this from happening.


Principle 2: Keep it flat

As a rule: Never nest CSS more than 2 levels. Otherwise it becomes coupled and hard to change. 
This  will require more classes in the markup but gives extra flexibility. This is also where 
Sass comes in handy by making it possible to store all states within the same CSS class by 
using the Sass parent selector (&) to detect our parent state class.


Principle 3: Break it down to modules

We always create one file per module to keep things lean and to make sure the files don’t grow 
too large. As an example, the "pod" module is  in a file called _pods.scss.

We still have CSS files for generic classes that apply in multiple places on the project. For example:
_theme.scss for global theme styles and colours.
_typography.scss for all the different font styles.
_forms.scss for form element styles.

This idea maps quite nicely to the structure outlined by the SMACSS methodology.


Principle 4: DRY it up

DRY (Don’t repeat yourself) is a common practise in programming that also applies to Sass code. 
In Sass we can use variables to store common values in one place. Variables have the added benefit 
of being extremely readable. Using our pod example and our DRY philosophy, the code will look something 
like this:

2. General Rules

If you can't CMD + F for a class in your pre-processed stylesheets that was output in the markup, 
then you’ve gone too far. If a class name isn't explicitly written anywhere except in the markup, 
it will make it harder to debug and track down in your stylesheets.

3. Pattern Library

Our Pattern Library gives us an extremely handy, navigable, and easy to disseminate overview 
of all the styles within our project. It includes all the visual elements of our website with 
all possible states, and is especially useful on a responsive project such as this where some 
elements have multiple states depending on multiple breakpoints.. It should always be kept up 
to date when new styles and components are added (this requires a team effort, but is worth 
it in the long run). Our Pattern Library is both a learning tool and a compass that corrects 
our course as we build new things. 

4. Handy Links

http://viget.com/extend/bem-sass-modifiers