Building better stylesheets involves blood, sweat, and often times a lot of tears, but that doesn’t always have to be the case. Working for a large company with an enterprise website has taught me one thing about maintaining stylesheets it becomes excruciatingly harder. If I still utilized the skills that I had five years I would be in serious trouble trying to keep track of the myriad of code changes and extensibility that needs to take place for newer designs and keeping old templates in sync.
In the current situations that I deal with on a daily basis my team and I find ourselves trying to update code that hasn’t been touched for at least 5 to 10 years. However, those old stylesheets while they may not be used anymore often have only a few connecting components between them all that make the design work. Our old practices involved keeping layout, design, color, and typography locked to certain stylesheets that all were needed in some small part and if you removed one for a page you needed to prepare for a page meltdown. In the past the process of a new design involved using !important tags (just made a few front-end developers cringe at that thought) in order to override older settings. That left us with CSS on top of old CSS to which the platform needed, but where does that leave us. Do we have to accept the practices of past employees or force us to accept that this will never change. The answer is a resounding, “No!”
When I was first exposed to Sass I didn’t see the benefit and was completely comfortable editing vanilla CSS on top of aged styles. This got old seriously quick with the sheer scale of the environment we were dealing with and when my manager decided that the entire site needed to be responsive my work on that project made it obvious that this method was not idea in any way. Creating modular stylesheets probably isn’t anything new but the concept is something that all front-end developers or developers in general need to adopt even if they aren’t dealing with designs.
Modular Design Now
In my projects now I start with Sass I utilize a set structure that helps me get started quickly and maintains the code base that I will be working with moving forward. My project folders include three subfolders for modules, partials, and libs for vendor related stylesheets.
|__ project/ | |__ css/ | | |__ main.css | |__ core/ | | |__ modules/ | | |__ partials/ | | |__ libs/ | | |__ main.sass
- modules/ - contains Sass code that won’t output directly to a stylesheet but is used to maintain mixins or config files that maintain the main stylesheets.
- partials/ - this is where the stylesheet construction happens and files here are divided by their specific usage or purpose within our site. For example, I might have tables, typography (fonts), layout, and colors broken down into individual files to easily change or modify their usage across the environment.
- libs - here is where I place CSS libraries that I am pulling for my project. If I were to use Centurion or Twitter Bootstrap they would go in the libs folder because they are frameworks that are helping to solve one area, but will not be the final site design independently.
The idea behind this type of file structure for code is to keep repetition to a minimum and to create better extensibility for future updates or revisions to the system. If a designer was to redesign the tables across our site in the past we would need to do a search for all tables and rewrite each individual file that we came across. Now for that same change I can change the table mixin file under partials and be done. The change would literally take a few seconds and could be LIVE and tested by the end of the day across our entire site, rather than taking a week to implement.
Layout Over Design
Another trick that I am trying to get other developers to adopt is the idea of building layouts first and then adding in all the designs. When I used to code designs years ago I started building in background colors and images, typography, colors, and so forth. It made my designs look good but now everything in the design was tied to that one stylesheet. What I try to do now is first build the skeleton for the site (the layout) and then put in the rest of the design independently. At first your layout will look like text and images on a white page, but you will have the scaffolding separate from the design and help to ensure what is called Object-Oriented CSS.
Using this same method when we move to our design we can add classes for the design that keep the layout separate. This is the same concept that I use with Centurion to keep the grid layout independent of the design. This way our designs can be pixel perfect with the layout and design without the developer going stir crazy adjusting pixels for each stylesheet that might be needed for a myriad of different pages. It is a win in every direction.
Interested in Sass
If your interested in learning about Sass I encourage you to head over to The Sass Way, a great website with blog posts about using Sass or if you feel confident head over to the main website for Sass for more in-depth documentation.
About a year ago I wrote a few posts about Sass. Considering I started out with vanilla CSS building when I first was exposed to Sass I didn’t see the benefit or the need of using