Great CSS can produce beautiful, responsive layouts that look stunning and users love. But we’ve all come back to an old project a few months down the line, scratching our heads and wondering where to start with the tweaks or updates we need to make. It’s not about your proficiency as a developer, and has nothing to do with the code you’re working on.┬áSometimes, in our enthusiasm, we can write a labyrinth of code that can be navigated at the time, but gets us lost when we return. It’s even more difficult if we’re looking at someone else’s code, or when someone else is looking at ours.

I frequently work on projects with CSS line numbers well into the thousands, often written by several developers. They can either be an absolute puzzle to decipher, or straightforward to browse and edit. The difference between the two can be achieved with just a few simple techniques. Here are some of the ways I make my own CSS a little more friendly.

 

Don’t be afraid to comment

Commenting is a way of including text that doesn’t affecting what your code is actually doing. It’s an extremely useful way of indicating things that the code alone might not, such as why a certain technique is being used or additional notes on what’s being affected.

In CSS, comments look like this:

/* Any text between these symbols, even onto
multiple lines, will be ignored by the browser rendering your CSS */

A forward slash followed by an asterisk opens the comment, and an asterisk followed by a forward slash closes the comment.

Sometimes we have to code something a little unusual to get around a particular browser quirk, or create an interesting effect. Lines of code don’t always show exactly what’s going on, so comments are a great way of explaining things to your future self, or another developer.

Comments are also a good way to divide your stylesheet into sections, and designate where each one begins and ends. This leads me onto the next tip.

 

Give your stylesheet some structure

Development projects aren’t always completely linear. You’ll often find yourself going back to continue styling part of the site that you’d started, but was being held up by something else. There may be amends later in the project, giving you a reason to go back. Sometimes it’s tempting to just keep adding styling to the bottom of the CSS file, so that your code is essentially in chronological order.

Problems arise when you or someone else needs to go back and edit, for example, the “Blogs” section of the project. If the styling for the page and any subsequent amends are littered throughout the stylesheet, it’s a much longer process to find everything you’re looking for. Styling being in the order you added it doesn’t help anyone when it’s time to make a change.

Consider structuring your stylesheet in the same way that your site is structured. Divide it into sections, separated simply by comments such as:

/* Styling for the Blogs page */

Keeping your code together makes it much easier to come back to. If it seems like more hassle than it’s worth, consider that not all HTML elements in your project may have semantic class names or easy identifiers. Using “Find” in your editor may seem like enough, but you won’t always know what you’re looking for, especially if you’re not the only developer contributing to the project. Organising your code in a logical structure makes it far quicker and easier to locate the code you need.

 

Mirroring the page structure

If you’re working on detailed pages with a lot of elements, even within commented sections things can get a bit confusing. You still might have several hundred lines for just one section. Where’s the code that styles the images? How do you keep track of the CSS for the body text? You don’t want to go overboard with the comments. Fortunately, you can also structure your CSS in a really simple way that makes it easy to relate to the content you’re working on.

Just consider the way your page is structured. You may have a title for example, followed by an image, followed by some body text. There might be a couple of links underneath that, and finally another image. Structuring your CSS in the same way is a really easy visual cue for either you or another developer to see where the styling they’re looking for might be. Have the styling for the title first, followed by the styling for the main image, then the styling for the text (and so on). It may seem like an obvious suggestion, but having a recognisable structure even without commenting can be a useful time saver.

 

Splitting things up

At this point you may be thinking “Can’t I just have more than one CSS file?”. The answer is yes, you can – but you might not want to.

Including multiple CSS files is another way to split up your styling into more manageable chunks. You might have one CSS file for your site’s main layout: the header, footer, background and so on. Another stylesheet may contain the styling for your articles, in an entirely separate file. You may even be able to selectively load the individual CSS files only when they’re needed, forgoing the article styling on the homepage, for example.

While this may seem like the perfect solution, it doesn’t come without its own considerations. More files means the web browser making more requests to the server for those files. On a lightning fast broadband connection, or stable wi-fi network, that probably isn’t going to be an issue. But with more and more users browsing the web on mobile data connections, the seemingly inconsequential milliseconds added by additional HTTP requests can really add up.

There are ways around this, of course. Some content management systems (CMS) will compile and compress your CSS into one single, “minified” stylesheet regardless of how many files you’re uploading to the server. But if that feature isn’t available to you, be sure to balance the number of CSS files you’re using against the potential impact.

 

Navigation within your stylesheet

If multiple CSS files aren’t suited to your project, or the ones you’re using are still pretty large, there is another tip to make life a little easier within a gargantuan stylesheet.

Quick-find codes may be familiar to some developers navigating text-only guides or manuals online. Making use of a browser or text editor’s “Find” feature, these codes allow you to navigate quickly to different parts of a document from a table of contents.

Most of the larger stylesheets I work on might start a little something like this:

[BLG] Blogs
[GAL] Galleries
[NWS] News
[USR] User Registration
[LGN] Login Form

Building a list of sections and adding a quick-find code at the start of the CSS file is a really handy way of making your stylesheets easy to navigate. It may seem like overkill at first glance, but if the styling for the News section is midway through a 4,000 line stylesheet, being able to press CTRL+F and type “[NWS]” is a pretty handy time saver.

 

Everyone knows their alphabet (mostly)

One final habit that’s good to get into is alphabetising your values. It’s pretty easy to see why it might be more difficult to find the value you want to change in this (slightly over-the-top) example:

#content-box div.example {
background-color: #FFFFFF;
display: block;
padding: 20px;
border-style: solid;
height: 120px;
font-size: 14px;
border-width: 1px;
margin: 10px 0 10px 0;
text-transform: uppercase;
border-color: #ECECEC;
width: 420px;
font-family: Arial, sans-serif;
border-radius: 5px;
position: relative;
font-weight: bold;
text-decoration: underline;
}

As opposed to this:

#content-box div.example {
background-color: #FFFFFF;
border-color: #ECECEC;
border-style: solid;
border-width: 1px;
border-radius: 5px;
display: block;
font-family: Arial, sans-serif;
font-size: 14px;
font-weight: bold;
height: 120px;
margin: 10px 0 10px 0;
padding: 20px;
position: relative;
text-decoration: underline;
text-transform: uppercase;
width: 420px;
}

It shouldn’t even be a conscious effort to locate the value you’re looking for; most of us know how to spot something in alphabetical order without even thinking about it.

 

Does it all really matter?

Absolutely.

These techniques may seem minor, but a few good practices can quickly work together to increase productivity. Efficiency is valuable; when you’re writing and navigating through hundreds of lines of code every day, even the small things show their value pretty quickly. Whether you’re working on small projects alone, or contributing towards a larger piece of development work, these are great time-saving habits to keep.

Don’t just do it for yourself. Even if you think you’re fine navigating your own code the way it is, the time saved when collaborating is far more noticeable. Explaining your code to someone else takes time; the more they can understand themselves, the better! It’s always a pleasant surprise as a developer to join an existing project with clean, coherent code.

 

What else can I do?

This blog entry was just to cover some simple coding techniques for making developer-friendly stylesheets, that can be applied not just to CSS but to coding in general.

For more advanced CSS optimisation on a development level, you may want to look into pre-processors and object-orientated CSS techniques, which are a separate topic that I may cover at a later date.

 

If you’d like to get in touch with me, even if it’s to strongly disagree with everything I have to say, please feel free to contact me or use the comments below. Thanks for reading!