On Cinco De Mayo this year, I’ll celebrate my 3 year anniversary as a front-end web developer. I’ve seen some seriously gnarly CSS in my time, but it wasn’t until I worked on a wide range of rescued websites that I saw some truly horrendous CSS and SCSS. We’re talking about the kind of things that make any seasoned front-end dev want to pull their hair out or bang their face into their desk while screaming “Why!!!??”
Here are a few nuggets of CSS horror:
1.) Knock it off with the !important rule. Seriously.
Let’s begin with the !important rule. In CSS, this is meant to be the proverbial nuclear option. It is the mother of all overrides. I have never actually needed to use it, until I was working on sites that built by developers from other (much lazier) companies. I had to use it, because they had used it and botched the CSS so bad that I had no choice but to override other styles when making basic changes. Just to give you an example, this is what I would see in terms of !important usage (note, this is not client code but dummy CSS I have constructed to demonstrate this atrocity):
.button {background: #000 !important; color: #fff !important;}
.button.blue{background: blue !important, color: #000 !important;}
.checkout.button{background: orange !important; height: 30px !important;}
As you can see, just about every rule has important on it, and it defeats the purpose of using classes in CSS. Classes are meant to be reusable CSS components that you can apply or remove from HTML elements to achieve your desired styles. Using !important like this will end up causing serious rule specificity, which can be difficult to override. This also causes a lot of bloat in your CSS. Which leads me to… too much specificity.
2. Take it easy on the specificity already
I have seen, even when !important is not involved, far too much specificity with classes and IDs. If you’re more than 4 classes, elements, or IDs deep into your CSS rule… something hath gone awry, and I urge you to back that CSS up. I’ve seen a lot of that with many of the sites we’ve inherited, where a lot of the CSS is overly specific. It generally continues to snowball until we can do a fresh build. Having bloated CSS slows you down over time. It makes easy tasks complicated as you try to untangle what you’ve done. Taking the time when you have a fresh build to review your comps and plan out what you need will save you lots of headaches down the road, and if I happen to inherit one of your sites, I won’t cry as I scroll through it.
3. And what’s with the empty brackets?
Speaking of things that make me cry and bloat CSS. I have found one of the most curious occurrences in CSS, when developers create CSS rules, and then leave an empty pair of brackets at the end. For example: button {} ←- why??? I’ve found it over and over in multiple CSS files, and on a variety of sites. It baffles me as to how that comes about. I also have to fight my OCD spend a bunch of time deleting all of them.
4. Commented out CSS=bad
I’m just gonna keep this short. Commented out CSS is almost as bad as the empty brackets. Why is that in there? It’s like taking down your old cabinets, putting up new ones, but leaving the old ones in the kitchen…
5. Name your files as if you want to find them again one day.
Now let’s talk file and folder naming. For the love of all code that is holy, if you’re working in SCSS and you make a mixin, indicate in some way that the file is a mixin. Don’t make a mixin folder with one file, and then stick all your mixins in a folder just above (looking at you Snowdog). Mixins should go in a mixin folder or have mixin at the beginning or end of the file name so it’s easy to file and you don’t have some poor dev grepping around to try and find it. That also goes for other files in general. For example, I have inherited a project that’s got 3 typography.SCSS files. They all have different pieces of the typography puzzle. One is a mixin for the styles, another holds all the standard variables for it, and lastly, one has just the standard SCSS for it. They are all named typography.SCSS, and they’re just in different non-descript folders. Coming into a new project and learning someone else’s SCSS, this kind of non-descript file and folder naming makes things confusing and time consuming to navigate.
Let’s all try to make this easier on one another and agree to avoid at least these five things forever. Please and thank-you.
