The problem of massive CSS
In the past few years, I’ve worked on several big websites as part of a front end team. And all those sites have the same problem: a cancerous growth of CSS. The problem starts out small; a designer changes the look of a new component of the site in such a way that existing CSS classes can’t be used, so the developer adds some new classes. However, over the years this process turns a few hundred lines of CSS into a few thousand lines (or even more than a few). And at some point the developer might not even try to reuse CSS code, because it’s easier to add a few more classes than to find the proper classes in all those lines of CSS. And so the problem of massive CSS is born.
So what is the solution for this problem? In my opinion, the solution has multiple layers. Firstly, for a large site a very strictly adhered style guide and component guide is a requirement. It might not be as much fun for the designers, but it is a very good way to maintain cohesion in the designs across a site. Secondly, build the component with reusability in mind. Don’t make them location dependent (i.e. it should be possible to put a component in the main column and in the sidebar without adding new CSS). This is quite difficult, but not impossible. If there is no other way, make sure to document this in your CSS and HTML. However, the hardest part to solving the issue is getting people on board with any new solution. People don’t like change, and there are actually people that thrive in the chaos of massive CSS.
Technically speaking, I think the best solution is Nicole Sullivan‘s Object Oriented CSS approach. Although the link goes to Github, it’s not only a technical solution, it’s a mindset solution (just like OOP). You need to learn to “see” the “objects” in a page that can work with the OOCSS approach. OOCSS also isn’t a silver bullet, you can’t use it for every single part of your website. However, it can work for the interface elements of your site: the elements that keep popping up all over your site. Things like content boxes, a picture with some text or a form field and label. The clue of OOCSS is figuring out a singular way of building a component and then sticking with it. Of course you can extend a component so that it becomes a new component (just as you extend a class in OOP), but you shouldn’t have two components that look similar on the same level in your “OOCSS hierarchy”.