Our Living Style Guide (Writing maintainable HTML/CSS)
info.rjmetrics.com
info.rjmetrics.com
But a living style guide is worth nothing if the team members willfully choose to ignore it and pursue their own style agendas (and they are personal agendas, make no mistake). I've implemented some seriously ugly interfaces in the name of consistency, and the project is better for it.
The biggest hurdle is convincing management that this new flashy module simply does not mesh with the rest of the software. Design wants to impress, management is impressed, off to the nerds to implement it.
To your comment about new flashy modules that don't mesh, banks seem to be the biggest transgressors in this area.
For the past 5 years or so I've had an average an average of 8 base css files for most projects, normally along the lines of page layout / typography / individual elements in different contexts / interactive elements & their mobile equivalents in separate files then a separate file for each ~type~ of content object within a page, sass gets expanded, then they get minified & cached as one file. Along with saving a hash of their internal paths to prevent the majority of cache misses, I've found this works well (for javascript also) & other than hand-tweaking a couple of homepages or high traffic landing pages haven't had to do much else.
edit: to be clear, the article is great advice but would have you end up with a monolithic common.css, don't do that, there are better alternatives
They make it easier for full stack devs like me to be productive without having to delegate every small thing to a designer or rely on everything being done up front.
I think others feel similarly. The proliferation of Bootstrap-powered sites proves it.