We’ve all been there – a new project kicks off, we have an established brand/style guide and there is an existing project which has implemented that style in its own image. The problem is, your deadline is looming, the authors of that original stylesheet are nowhere to be found (or deny an involvement despite the git logs suggesting otherwise) and you have to ship. In a moment of despair, you re-implement that style sheet in your own image – thus contributing to the ever-mounting CSS debt. Wash, rinse, repeat.
But it doesn’t have to be this way, with a bit of effort sharing CSS between projects can be simple. And I think it’s effort that will pay off. Think of it like creating your own version of Twitter Bootstrap.
Why go to the trouble?
- It helps to give your apps a consistent look and feel.
- It makes creating new apps faster; which is especially helpful in a micro-app/micro-service environment.
- It allows your front-end developers to concentrate on the “hard stuff,” e.g. the fancy widgets and transitions which give websites an edge.
- It allows your part-timers to get stuff done without having to learn every nook and cranny of CSS.
- It speeds up the rollout of new design themes.
So what’s the secret sauce?
Create a single code base
Ensure that all developers are working off the same codebase. Forks/branches should be avoided (unless it’s a short-lived spike). By doing this, your front-end devs will have less inclination to do things as they see fit on the parts and be encouraged to work co-operatively on the whole.
Agree on how to make changes to it
I recommend managing the code base like an internal open-source project. This includes selecting front-end developers from each team who are given commit rights to the code and who meet periodically to establish processes and idioms. Processes might include the format of pull requests, how code-reviews are performed and how code should be submitted to the master branch.
Make it available to everyone
Some projects use preprocessors such as SASS or LESS while others use plain CSS. Some are written in Ruby, some in Java and others in “hot new” language X. The code needs to be made available to all these consumers without duplication. This can be made possible by layering your interfaces. The plain CSS interface can be layered on-top of the SASS interface. Similarly, a Ruby Gem interface can be layered on top of a file structure which suits a CMS project by mapping the structure to something the Rails asset pipeline can digest.
Version it
This should go without saying. To ensure browsers always pick up a consistent set of styles I recommend using tags (e.g. Github releases) to manage this. All projects should consume a specific version of the code-base to insulate themselves from unplanned change.
Provide a small and performant “core”
Don’t put everything which anyone could possibly want into one compiled file as this will cause CSS “bloat” and slow down page loads.
Concentrate initially on creating a core file, which gives you things such as:
- Vertical cadence/spacings, e.g. line-heights, vertical margins etc
- Colours
- Typography, fonts (e.g. styling for body text, h1, h2 etc)
- Styling for the commonly used HTML elements
Put the other stuff in optional modules.
This could include:
- Grid frameworks
- Widgets – e.g. dialogs, message boxes, spinners
- Legacy browser (e.g. internet explorer 8) workarounds
Provide an additional “-all” CSS file with everything included if useful and convenient.
Use the “C” in CSS
The “cascade” part of the CSS name has often been overlooked recently with a lot of focus being put on object-oriented techniques and pre-processors. Let’s bring it back!
For the “core” file, use idioms such as the (http://alistapart.com/article/axiomatic-css-and-lobotomized-owls) to keep the CSS compact and easy to override.
For the optional stuff, use namespaced selectors. One way of doing this is by using classes following the BEM syntax. A newer (and IMHO better) method is the (http://glenmaddern.com/articles/introducing-am-css) which uses attributes rather than classes for styling and doesn’t rely on pre-processor directives (e.g. @extend) to remove duplication.
Make a living style-guide
I recommend making it mandatory to keep the style-guide in sync with the code.
A style-guide does several things:
- It provides a way of “regression testing” the CSS prior to its consumption in a project.
- It allows everyone to see what’s provided so no one reinvents the wheel.
- It helps part-timers to use the CSS, allowing them to copy and paste fragments of HTML (Note that this should only be done where appropriate).
There are several tools (e.g. KSS, Style doco) which allow the style guide to be created via inline “comments” in the CSS source files. These tools make it easy to spot gaps in the style-guide.
In order to be used effectively the style-guide should be published somewhere accessible to everyone.