CHAPTER 1 Modern CSS Architecture and Front-End Development
CSS, and changing a few classes in your markup is far easier than refactor-
ing tangled style sheets.
In preparation for a talk I gave in mid-2013, I decided to conduct a
very lo-fi and unscientific experiment. At work I’d built a fairly large site
over the previous six months, containing loads of view files using lots
of classes. I had to make a far-reaching change which involved editing a
class which appeared in many places across many of those files. I decided
to time this process to see just how much effort was involved in changing
a few classes in markup used across a whole site. It took twelve minutes.
That was it. I have lost entire days fixing mangled CSS. Whole, full days.
By using these extra classes I had totally granular CSS which was a joy to
work with, and making changes across this entire project took less than a
quarter of an hour.
The reason it was so fast was simple: automation. You can automate
find and replace but you cannot automate CSS refactoring. My process was
simple. I just ran:$ git grep "$CLASS_I_WANTED_TO_FIND"This gave me a list of all the files containing that class in my project.
I then opened all these files in my text editor and ran a global find and
replace. Easy.
The overhead of these extra classes is nothing compared to the effort
involved in reworking CSS. Take the easy route of adding more classes and
use automation (grep, ack, sed) when you need to change them.
The other thing I often tend to say in this situation is this: you are a
Web developer, it is your job to maintain code. Instead of complaining
about having to change some code you wrote, begin to embrace ways of
doing it faster.
So if classes don’t impact semantics, and no one cares about how clean
your markup is, and more classes aren’t that much harder to maintain, I
think it’s time we embraced them a little more.