DRYing up CSS
Albert Einstein once said “Out of clutter, find simplicity.”
For the longest time, I did not understand what he was trying to convey, but then I started interpreting it by testing it’s applicability in aspects of my life. My interpretation has since been ‘de-duplicate and reuse’. I have since been able to go lean to a good extent on many things I do. Be it all the stuff I have in my basement, in my closet or my code.
As a UI developer, when I find myself writing/reading CSS code, I find Mr. Einstein’s advice holding its water so well that every bone in body wants to refactor the CSS. We all focus these days on choosing the best UI framework or how UX is so important. But when you get down to business, i.e. code, CSS is usually the neglected child. It is all over the place and it is not easy to refactor without guaranteeing styling regressions.
We deploy cool tools to minify it, optimize it, comb it and all other goodies. But I have observed in various projects that of all the core ideas behind CSS, reusability of styles is the most overlooked one. It is still code, and if we are repeating it, then like all other code that is not DRY. It is cluttered code and a liability. Discipline to keep CSS rules to as few as possible yet having them be reusable through an enterprise web app, is often missing. And as developers, regardless of seniority and experience, we all make these mistakes in the process of getting stuff done ASAP or just exercise laziness in the name of a later-refactor-spike, and leave duplicate CSS crumbs throughout the codebase.
Decluttering is critical because it feeds into the speed of writing new UI, changing look and feel in one fell swoop or just plain old refactoring. So here are some of the questions I like to ask (or provide answers to) with a team when CSS is involved:
Do we have Preprocessors?
If you are not using LESS or SASS, kudos to you. You have heart because these not only reduce the time it takes to write CSS, but also coming up with DRY patterns that I am professing here. For the purpose of these thoughts, let me assume we are using LESS.
When do I start?
If you are starting a project or a web application, then it is a no brainer. But if you have decided to change tires while running the car, then a piecemeal, small chunk approach is best. Large scale changes are OK, but then in my travels, it has worked best when there is constant communication between developer and the feedback loop with UX designers is small. Of course there are tools like CSS Lint, where you start with whole CSS codebase and break into pieces. In any case, simple agile approach is to find a page that has largest number of style patterns, break them down just as if you were paper prototyping and come up with style buckets, which brings me to the next point…
Where do I put this?
Yes, a simple common sense approach of feature (or even page) based CSS files is prevalent these days. However, there needs to be places like forms.less, commons.less or control.less which just by file naming convention itself, tells a team member what goes where. For example, if there are constructs like panels as dictated by UX and they are going to be repeated throughout the UI, we need those in panels.less. First person to write does a harder job, yes, but then we all thank him/her by reusing and owning the DRY code as a team.
What should I name it?
This depends entirely on the team. While file names are easy, class naming often becomes a dragged out “topic” at work. SASS has great conventions on doing this. No reason why it cannot be applied to LESS or even vanilla CSS. BEM (block, element and modifier) is a good approach as well, but you end up writing long class names. Class names can just be functional (what it does), presentational (what it looks like) or content-based (what it contains). Regardless of the convention but with a consistent approach, this can increase maintainability multi-fold, especially if you are in the business of making your own UI components just identified by classes. This also helps the team relate to the CSS codebase quicker as a living document rather than just a code artifact.
Is this reusable?
This is the hardest thing for a team member to get used to. If you are implementing a new UI page and you are going to add a good chunk of styles, then it is great to be conscious of offering your work as reusable modular patterns. But it is not always the case. More so in fast paced environments. This is where code reviews play a crucial role in enforcing reusability and identifying patterns. Pair programming CSS with a buddy is a luxury, but man! does it pay dividends. I have benefited from that first hand. Bottomline: once a start is in place, then you just follow up in the code reviews until is becomes a culture.
How do I use it?
Ah! The $64,000 question! Well, if the good work has been communicated well, then the answer is just one link in a Slack message away. Checkout the docs from Ionic framework or Bootstrap. Personally, these are the epitomes of how usage of UI constructs should be communicated. Same approach can be taken for in-house CSS styles and patterns. The documentation does not have to be this fancy, but an internal wiki or Github wiki with screen shots coupled with HTML decorated with class names is a darn good start. If your team is not lucky enough to get a set of styling guidelines from an army if UX designers, then this wiki becomes one.
Lastly, another simple analogy that I would like to share is that CSS is no different that say, Java. Think of CSS way of doing a Java class with reusable utility methods…catch my drift?
