During the last six years of SAGrader development, our small team has constantly battled our style sheets.
With every new feature comes questions like: Is there an existing class I should be using for this element? Is this supposed to be a H1 or an H2? What color should this border be? How do I put a sidebar here?
In practice, every new feature we built included another 100 lines of specific CSS classes. This made development more difficult for our developers (who should be concentrating on building magic functionality not redesigning our app) and left us prone to inconsistent styling (left up to the discretion of the developer).
One solution has been to use a CSS pre-processor like LESS. At the very least, LESS allows us to use variables for commonly used elements like colors and typography.
But after doing some research, we found that LESS is only a band-aid for a systemic problem. It turns out that many other groups have the same problem we do, and the solution is to re-think our approach to CSS.
When designing CSS for a large application being developed by many people, it’s important to optimize your CSS for re-usability. This means throwing away many of the CSS basics we learned in 1999.
For me, the main takeaways have been:
- Separate different types of styling. Most importantly, separate structure from chrome. This allows for easier mix-and-matching.
- Minimize the depth of applicability. Creating six levels of descendent selectors couples CSS too closely with specific markup.
- Avoid over qualifying selectors. Keep them as general as possible so they can be reused and combined.
- Get in the habit of using multiple classes on elements rather than one huge single class.
We’re working on implementing some of these strategies over the next few months, and I’ll be interested to see what actually works. Our goal is to give our developers a flexible CSS framework that can be quickly and easily adapted as SAGrader evolves.
In the meantime, our battle with style sheets continues.