CSS structure is an issue many of us deal with daily. The dynamic development environments teams face determines how any projects CSS is written. Ultimately the goal is to reduce duplication's and write our CSS so it easy to manage and cascades as efficiently as possible.
At the West Virginia University Health Sciences Campus we have unique scenarios due to the broad range of apps and websites we develop. Because of this we have struggled to have a consistent CSS base throughout our products that can seamlessly be worked on and maintained across our team. We also encountered a lot of bloat in our CSS from replicated elements and being overly specific.
In last few months we have been focusing on how to resolve our CSS problems based on these project branches. Initially we needed to establish guidelines for our CSS structure. We chose SASS for our CSS extension language and built on that by having more open discussions about the decisions we make when writing CSS. After reviewing external approaches to how other teams write their CSS and reviewing how we work with our back-end developers we decided to go with DryCSS and OOCSS practices. Beyond these we agreed on standards for how to break our CSS down into more digestible pieces. We began creating more practical partial SASS files but there was still an issue concerning how our CSS cascaded. We faced conflicts about when more specific pieces of our code were implemented. Our CSS had become more practical but still wasn’t being structured well enough to avoid expensive specificity declarations.
The root of our specificity issues was with where our CSS lived. Elements were too often being pulled into other partials which made our CSS bloated and overly complex. Midway through our evaluations I stumbled across a method that Harry Roberts put together called ITCSS (Inverted Triangle CSS) which focuses on how to better manage these problems. Through testing and reviews it has become the most beneficial solution to our specificity and organizational issues. ITCSS allows our front-end developers to be more agile from project to project. It has also further reduced our replication and file sizes.
SASS (CSS Extension Language) - http://sass-lang.com/
ITCSS - http://t.co/b9D1R9HJLB
With these guidelines in place we now write our CSS using SASS with a healthy mix of DryCSS and OOCSS. The combination of these concepts helps our team reduce over-nesting in SASS and reduces any unnecessary duplication of code. Additionally our CSS is now more structurally sound and can scale at a quicker rate.
Aside from the base code development we write specific and obvious partials which follow the ITCSS concepts. The only real changes we made on top of the ITCSS concept was adding an additional overrides (otherwise known as trumps in the image below) layer below the core overrides. This adds one extra level which allows for apps and websites to implement more specific code changes beyond the core suggested structure. If you watch Harry’s talk you will find he encourages these adjustments to suit your projects needs. Having specific locations for where each level of CSS lives has drastically improved how maintainable our code is.
Below is the resulting structure of one of our projects using ITCSS.
Moving forward we will continue looking for more solutions to implement so our team can more effectively work in any of our projects. If you find yourself looking for better solutions to your teams CSS I would advise trying any of the concepts listed in this post. Each have helped to make our code more maintainable. ITCSS in particular has helped to clarify what was once a very convoluted aspect of our CSS development.
If you have any questions or thoughts feel free to tweet me @sk_5 and I will be happy to offer any answers or insight. Thanks for reading and I hope this can be of help to your CSS process moving forward.