This document outlines the way Customer Success team is expected to write their CSS. Following this document ensures that everyone is writing markup that feels familiar and can be maintained by anyone with little overhead.
We follow a mixture of various methodologies include, but not limited to: SMACSS' seperation of concerns, OOCSS' modularity, Topcoat's coding guidelines, BEM-ish naming conventions, and others.
- Sass is our preprocessor of choice
- Susy is used for our SASS-based grid system
- PostCSS for its Autoprefixer plugin
- Sass-Lint is our preferred linter for
SCSS. Our custom linting rules are found here). Find out how to integrate Sass-Lint with your text editor here. - CSScomb is a tool that can be plugged into most popular text editors that automatically formats your code! Our formatting ruleset can be found here. Find out how to integrate CSSComb with your text editor here.
We strive to write modular, component driven CSS with a clear separation of concerns, structured so they are re-useable and findable. In the end, our code should be easy to maintain by anyone.
These guidelines are a summary of our base principles: Our code bases should all...
- Be written like a single person typed it
- Be mobile-first
- Be modular: components are better than page specific styles
- Be page specific only as a last resort
- Be written with nesting no deeper than 4 levels
- Be written with selectors that self document their location
You may notice the heavy influence of methodologies like SMACSS and OOCSS.
Familiarity with these concepts is crucial! We urge that you at least learn the basics: Jonathan Snook's "CSS is a Mess" and Andy Hume's "CSS For Grown Ups" are good places to start.
Continue on to CSS Best Practices →