CSS and 5 mistakes to avoid

Just yesterday I was working with smaller startup and their front-end division. The main objective was to fix few bugs and cross-browser issues and also to make the whole website responsive and mobile-friendly. Since this was not the case of bigger site, I thought it would be easy and fast to get done. Nice illusion indeed. A brief look at the CSS was like a punch to the face. It was a mess. This was not going to fruition in the meter of a few weeks. In this post I want to share with you couple mistakes to avoid if you want to keep CSS in shape.

CSS Specificity

Let’s take the one of the most often overlooked things in CSS by beginners and people who think that knowing CSS and writing good CSS is the same thing. Unfortunately, as with many other things in life this is not true. Anyone can write a poem or book, but they will not be the same quality. Writing good CSS is not easy. Specificity is a crucial factor to look for when working on any project because it works like a boomerang. If you shortcut it in the beginning, you might find yourself in messy situation later on.

The higher the specificity in your CSS is, the more effort from your side it will take to overwrite certain rules. This is something I call over-dimensioned selectors. You probably experienced this already on your own. It is any situation when you have an CSS rule or set of rules for some HTML element and instead of using one or two selectors there are four, five or even more descendant selectors on one line. The same thing is when you use HTML element with appended class selector.

BAD CSS:

#smartbanner #smartbanner.no-icon .sb-info { … }
body.next.none-content section div.in div.container .content-text p a.red-button:hover { … }
section .nav li .link i { … }
header .address span.name-city { … }
section.main .content p { … }

GOOD CSS:

section p { … } /* or better just p { … }*/
.btn-primary { … }
.link-icon { … }
.musthead { … }

Some of you may argue that in order to keep CSS specificity as low as possible you will have to clutter your markup with bigger amount of classes. You are right. However, the goal of class attribute is to allow styling of specific HTML element, so you are basically following the recommendations given by people who invented them. It is maybe in a bit extreme way, but if it works? Think about this … Is it better to create more classes or to use 17(!) selectors?

Id’s in CSS

Using id’s in CSS is often discussed and you can find couple questions on this topic on Stackoverflow. Even though there is no set-in-stone rule that says:“Keep id’s from CSS.”, I suggest you to do that. The main goal of id’s attribute is to specify a unique id for an element. In other words, it is used in markup only once, not more. Your goal in your CSS document should be the exact opposite. You should aim for modularity, i.e. creating classes and rules that can be repeated many times over and over again without modification.

If you are using id’s, this is impossible. Every rule you use through id selector will be applied only once per page. Did you hear that applying styles via id is faster than via class? Me too. Did you see the difference? It was about 13(!) milliseconds. Is this difference big enough for you? Strong argument against using id selector in CSS is that it is the beginning of a downward spiral into specificity or, to be more creative, specificity wars.

BAD CSS:

#header .link { … }
#main { … }
#footer .icon { … }

GOOD CSS:

.header-link { … }
main { … }
.footer-icon { … }

The next time you will want to override id selector you will need to use another id with either element selector, class selector or … Two id selectors (Don’t try this in your project please!). Wait a minute, you can also use !important declaration! No, no, no. Let’s make it easier forgetting id selector completely when you work with CSS. Keep it only as a hook for JavaScript.

Lack of organization

This is a problem I see when working with bigger teams of developers working without any guidelines or organization they should follow. In case of team of one it is not such an issue. However, applying some coherent style to your CSS documents is always a good idea. Structuring CSS can mean a lot of things. For example, it can be something “small” like sorting the properties in certain order. On the other hand, it can also mean organizing whole stylesheet in specific way.

CSS from csswizardry:

/**
 * CONTENTS
 *
 * SETTINGS
 * Global...............Globally-available variables and config.
 *
 * TOOLS
 * Mixins...............Useful mixins.
 *
 * GENERIC
 * Normalize.css........A level playing field.
 * Box-sizing...........Better default `box-sizing`.
 *
 * BASE
 * Headings.............H1–H6 styles.
 *
 * OBJECTS
 * Wrappers.............Wrapping and constraining elements.
 *
 * COMPONENTS
 * Page-head............The main page header.
 * Page-foot............The main page footer.
 * Buttons..............Button elements.
 *
 * TRUMPS
 * Text.................Text helpers.
 */

The degree and size into which you want to take it depends on you. However, no matter how small or big step will you do, it will only be a step forward because coherent (this is important) structure will help you understand and orient in your older projects, even if you forgot what it was about. So, have a courage, experiment and see what works for you.

Various coding styles

One more thing common in bigger teams of developers is various styles of coding. From different indentation to order of properties to zig-zaging with parts of stylesheets. I know that things like if you indent your code for two spaces or four is just a small detail, but it’s the details where every problem begins before it grows into something bigger. Only by watching for this minor issues can we precede the troubles before they become more serious.

Tech company, and other too, strive to create a good culture for their employees. What they should also do is to consider creating a consistent culture or environment when it comes to development and programming. It is great to have team full of amazing developers working together and it is better if they follow the same style. If you need some inspiration, take a look at styleguides from GitHub for CSS or Airbnb’s JavaScript or code guide done by @mdo.

Poor commenting

In many situations comments are often misused or not used at all. What a pity! Comments can be great way to put order into your code and to help your colleagues understand it faster. Another example of using comment the good way is to include a meta information like author, contact, date, version and license in the beginning of document. This is not about being narcissistic. With this info included, anyone working with code will know who is the author and where should he seek help or more detailed documentation.

However, comments can be a double-sword weapon, so think twice about why you want to use them before writing anything. Your intention should not be to write comment about every short snippet of code. Use comments when there might be problems with understanding the code and what is its function. If you are afraid of size of the CSS files, use development and production version. The difference is production version is minified, so without comments.

Summary

There are many ways how CSS can break your project. These five I shared with you today are the ones I often see when working with clients. These are also relatively easy to find and fix and can have significant impact in the future. I hope this will help you, your company and clients work faster, easier and deliver better results. What other things about CSS to avoid would you like to share?

If you liked this article, please subscribe so you don't miss any future post.

Subscribe

If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂

Become a Patron Donate via Paypal