Recently, I’ve been rewriting entire style guide for Lifetramp to Sass, to make it a living style guide. My reasoning for that was simple - style guides are usually the most unsexy thing in the product design process and maintaining one that works is usually a pain in the backside. Since the first version of Lifetramp will be working on a Rails backend and Sass is a very viable option, I’ve decided to go with the approach, inspired by this talk by Jina Bolton, that I’ve been using before with Clockwork - a living style guide that is being kept up to date with modular Sass and needs to be maintained only when you create new UI elements.
There’s two major upsides to this approach - first of all, because everything design-related is in your application’s Sass files anyway, the style guide keeps updating itself automatically every time you change anything in the styles. Also, because it’s Sass, you can keep everything in mixins, extendable silent classes (
%) and variables and it’s really quick to update and maintain if done right. The biggest upside for me is ability to spot errors, inconsistencies and edge cases in design just by glancing at the style guide test page.
The minor obstacle is that you really have to wrap your head around modular CSS architectures like SmaCSS, BEM or OOCSS, understand how they work and either choose one that works best for you or mix and match it into your own modular system. Actually, this might turn out to be an upside after all, since you end up learning new things and writing more efficient selectors, too.
If you haven’t tried the modular approach to CSS and using Sass style guides yet, I highly recommend you to try. While it seems like boring work, because we’re all so creative and prefer spending time doing creative stuff, if your project and team grows quickly, you’ll thank yourself for spending that time learning.