During the back end of last year I started to experiment with one of the more boring aspects of CSS, but one of the most rewarding in the long-term: How I actually write, organise and maintain my CSS files. These are relatively minor tweaks, but I thought I’d share them in case anyone finds them useful.

I’d just like to note that these are my personal preferences, you may disagree entirely with the way I do things and that’s fine, feel free to drop a comment below if you’d like!

Single vs. Multi-line

So lets get this out of the way, I hate single line CSS rules, they’re a pain-in-the-ass to navigate and can cause problems with some source control tools which may only tell you which line has changed and not which property has changed specifically or when running your code through the validator and getting errors which refer to specific line numbers as well as times when you might not have syntax highlighting to help you quickly visually identify properties and values (such as viewing CSS in Firebug).

I’ve never written my CSS rules as single-line and I doubt I’ll ever start.

Ordering of declarations

One of my most common bugbears is with the ordering of declarations, a lot of the CSS files I come across in my ‘day job’ are simply not ordered in any meaningful way, some have a semblance of ordering based on the personal preferences of the designer and may have width & height rules together, floats and positions together for example, this always differs from designer to designer.

The best way to order declarations is alphabetically, it makes it far easier to scan through and visually locate a specific declaration, especially in large rules. Also, for teams of multiple designers it’s far easier to add declarations to an existing rule as they simply slot in alphabetically.

Curly braces

This might be one of those decisions where people think “Does that *really* matter?”, but I’ve started to place my closing brace on the same line as the last declaration. The reason behind this is to improve the visual distinction between rules which helps when scanning quickly through a large CSS document.

Previously, I’d place the closing brace on it’s own line, like this:

Now that the brace follows the last declaration it improves the spacing between rules, or course I could simply add another line after each rule, but that simply adds to the filesize and needlessly pads out the document. This method also places all of the selectors on their own tab level which helps when scanning through to locate a selector.

Closing semi-colon

The closing semi-colon on the last declaration of a CSS rule is optional, while some people will no-doubt argue that dropping this will lead to smaller filesizes I’d always argue that long-term maintainability is more important, especially on larger projects with multiple developers or for projects which are handed to clients to maintain themselves.

By keeping the closing semi-colon in place anyone can quickly dive into the file and add rules without needing to worry about where the semi-colons are.

Further reading

I’ve only skimmed the surface of CSS coding standards to highlight some of the ways I like to do things, If you’re interested in making your CSS more readable, and especially more maintainable then I’d highly recommend you read the PDF version of this BarCamp presentation by Natalie Downe on “CSS Systems for writing maintainable CSS” which is a must-read and chock-full of excellent advice.

What do you do?

Do you have any personal preferences when it comes to writing your CSS? Feel free to hit the comment box below and let me know!

Disclaimer!

This theme isn’t finished, isn’t cross-browser tested and probably doesn’t validate. It’s to be considered a work in progress which I was just too impatient to keep hidden.

When it comes to embedding a company logo into a page, quite often the logo won’t be suitable for print. For example, the website may be dark and the logo might be light and while this works fine when the site is viewed on-screen, it can look out of place when used in a print stylesheet or if the site is viewed with CSS disabled.

While building the new University of Leeds corporate website we got to the stage where we needed to build our print stylesheet, the page header has a white logo on a dark background.

Originally, the logo was inserted into the design using a standard CSS image-replacement technique:

Light logo on dark header

When you’re using a CSS image replacement, the image doesn’t exist in the markup, it’s applied as a background image and only the h2 text is displayed. We toyed with the idea of using the same image replacement technique in our print.css, replacing the logo with the black-on-white variant. This quickly fell on it’s arse, as most browsers are set by default to not print background images as seen below.

Image replacement with CSS disabled

Putting the image back into the markup

In order to get around this, we decided to stop using image replacement and go back to having the image in the markup. Initially I was curious as to the effect of this from an SEO standpoint and had a quick chat with an SEO friend about the disadvantage of not having our corporate logo as a heading. He pointed out that there would be no disadvantage to us as we’re not trying to rank on the ‘University of Leeds’ as a keyword and that as it’s mentioned everywhere else in the thousands of pages we manage, it’s not going to make a difference. (Your mileage may vary and this might not be suitable for everyone)

Doing it bass-ackwards

Once we’d put the image back into the markup, it showed up as expected in our print stylesheet, however our white-on-black logo wasn’t really suited.

Same logo with CSS disabled

We already knew that we couldn’t use CSS to replace this with the black-on-white logo in our print.css, so we decided to do it the other way round. Rather than the have the white-on-black logo as default, we changed to having the black-on white as the default meaning that our no-css and print.css got the correct logo. We used a “hidden” class so we could hide the default image and a CSS overlay on the anchor tag to bring back our white-on-black logo to fit in with the rest of the design.

CSS enabled

CSS disabled / print stylesheet

Conclusion

Because most browsers disable background images when printing by default, you need to be aware that any important images that are using image-replacement techniques may not work. Working around these limitations is possible with a bit of planning.