Useful tips for writing efficient CSS

Jonathan Snook has posted a few great CSS coding tips in Top CSS Tips. Several of them come down to personal preferences, and it seems my preferences differ a bit from Jonathan’s in some cases, so I thought I’d go through his tips and note my take on each of them.

px for font sizes

Jonathan’s arguments for using px make sense, but I always use em. I’ve learned how to use a combination of percentages and ems and feel comfortable sizing text that way.

CSS declarations on one line

Unlike Jonathan I use a single line for rules that only contain one declaration, but multiple lines for rules with multiple declarations. TextMate’s code folding takes care of the rest for me. Jonathan makes a valid comment about file size savings with single line declarations though.

Blocking the Styles

I do pretty much the same thing: first element declarations, next global classes, and finally the layout containers and sections.

Browser Support

Jonathan suggests supporting only the latest browsers. I agree, but can’t always go all the way. However unless specifically requested by the client, IE/Mac gets no CSS and IE/Win 5.* will suffer the consequences of their faulty CSS box model (which I try to avoid anyway). I do like to keep the few hacks that are needed for IE/Win in a separate file, loaded with conditional comments.

Containing Floats

Jonathan prefers overflow:hidden while I almost always use the method described in How To Clear Floats Without Structural Markup at Position Is Everything.

Understand Overflow

Yes, realising that IE doesn’t handle overflow correctly will make it easier to understand what is going on when floats start dropping.

Allow Block Elements to Fill Their Space Naturally

Very good tip. Not specifying both width and margin, padding, or borders for an element will avoid most problems with the CSS box model in IE 5.*.

Use CSS Shorthand

I am a bit of a shorthand fanatic, so I agree. I even wrote an article on CSS shorthand: Efficient CSS with shorthand properties.

Avoid Unnecessary Selectors

Another great tip. I make an effort to keep my selectors as minimal as possible. I have seen stylesheets where selector verbosity has gone completely out of control, resulting in huge filesize overhead.

Keep it Simple

One of my main guidelines, so I agree fully.

Posted on October 25, 2006 in CSS, Quicklinks


  1. “I almost always use the method described in How To Clear Floats Without Structural Markup at Position Is Everything.”

    Interesting. How come? I’ve found it annoying as it’s 5 lines every time I want to contain a float, as opposed to just one.

    “IE/Mac gets no CSS”

    Given that even Microsoft don’t suppport Internet Explorer on the Mac (and actually advise people to use Firefox or Safari, I think?), I reckon that’s quite fair given the amount of work it’d be to work around its bugs. I don’t even bother to filter CSS from it any more, just like Netscape 4.

  2. October 25, 2006 by Roger Johansson (Author comment)

    paul: I find the easy clearing method very reliable, and I don’t always want the side effect of overflow:hidden (clipped content). I don’t think five lines or one really matter a whole lot since you only specify it once. To each his own though :-).

    I don’t even bother to filter CSS from it any more, just like Netscape 4.

    You mean you let them see the same CSS as more recent browsers? I really think you should be hiding the CSS from them instead, since that will at least give people using really old browsers a chance to access the content.

  3. I’ll have to agree with you on nearly all counts.

    One major gripe I have when debugging other people’s pages is unreadable formats. The formatting of the html and css, ok, the scripting, too, should be done for ease of scanning with the Mark I human eyeball. The bandwidth overhead is trivial for a text file, and the css and js are loaded only once, anyway.

    One point should be made. Tony Aslett’s clearfix hack works very well. Like all methods of clearing or enclosing float elements, there will be a set of circumstance that breaks the method. There are six methods, that I know of, for enclosing a float, one or other of which will work in any situation.



  4. Jonathan’s article was quite a nice reading. It turned out I’m about the same as both of you when it comes to structuring and writing CSS files.

    When it comes to font sizes I’ve up until now used em’s or in some rare occasions percentage - mainly because of IE but also when creating elastic designs it’s natural to me.

    I’ve noticed it sometimes gets problematic when working in teams though (in big projects where it’s hard to get a good overview) because of it’s inheritance. So now when IE7 has the zoom feature I’ll probably go back to pixel font sizes in projects where I’m not working alone on the CSS.

    When it’s only declaration, it doesn’t deserve more than one - that’s it.

    I tend to write the CSS in my main style sheets in a similar way as Jonathan. I don’t use the universal selector to remove margins and paddings. I usually remove top margins on most elements and some other things to make my life easier. After that I have some generic classes like the clearing method from Position is everything, etc.

    When it comes to supporting browsers I’d really like to support as many as possible but as it might get very time consuming on some sites, it’s mainly the modern browsers that gets attention.

    “Allow Block Elements to Fill Their Space Naturally”, that’s something I know I didn’t strive after before but now days that’s my preferred method.

    Selectors is something I can say I haven’t mastered yet. I sometimes find myself cleaning up a lot of unneeded selectors.

    And one last thing… conditional comments is probably one of the best features Internet Explorer has :)

  5. Great info, I’ve applpied most of them already, but you learn something new every time.

  6. If the idea is just to save a few bytes on the file at the expense of readability, I’d say don’t bother. Most web servers auto-gzip their payload, rendering things like extra spaces and lines neutral with regard to download size.

    The problem with px font sizes is that they don’t scale in IE (7 may be different), whereas ems do. That said, non-px based declarations are not size-consistent across browsers, nor platforms.

  7. Excellent reference. I noted a lot of similar practices of my own such as your first point regarding font-sizing. (Though I did note some differences too, and I won’t comment on all of it.)

    Font-Size: I never use px, or worse pt. Rather I always begin with a percentage such as 100.1% on body then em thereafter, but it depends. Sometimes it makes more sense to throw in some percentages depending on the child-parent relationship.

    Writing CSS: I tend to place all my CSS in blocks versus on a single line, but it depends on the size of the sheet. If it’s getting long I will sometimes close things up so I don’t have to scroll so much. As a general rule I follow my own rules and try to be consistent with them.

    Case in point, as I have done this for a while, when writing CSS in blocks I will add spaces like so and start two spaces in for each property/value declaration:

    element {
      property : value;
      property : value;

    But if written in a line, such as in the head of a document or inline I close it up like this:

    element { property:value;property:value; }



    I can’t say I have any justification for doing so other than it’s clear to me and has become habit, but I am consistent (with any of my newer works), and this is an important part in my opinion… in addition to employing the power of the cascade (a limited number of selectors) and keeping it simple.

    Regarding Shorthand: I tend to use it only with certain things: backgrounds and borders mostly, though I have been using a bit more with fonts. I appreciate the link in your article. Maybe I’ll study up and use shorthand a bit more to save space.

    Clearing Floats: I’ve never employed the “clear fix” method but I can’t say I’ve ever had a need to use it as I have either successfully avoided it by keeping the parent container longer that its floated object, or by employing another method such as displaying a block element with clear:all applied underneath (but not an empty unused one). Maybe at some point I’ll have to, just like using !important which is something else I’ve never used or found a need to use.

    Organization: I pretty follow your same method of sheet organization starting with * and body and such, then non-specific global elements, then global classes, after that I tend to follow the page as a guide as I find this is a good way to find stuff, but I’ll typically terminate the sheet with form styling. (My methods are still being refined.) I know of a couple of people that go in alphabetical order but I can’t say I care for that method.

    Plus One: I will add a tip which I personally find helpful is to use a handful of logically-named semantic class names and IDs and sticking to them site after site after site. I find this very helpful in that if I have to go back I don’t have to first study the CSS or View > Source to know what I’m after.

  8. I must be a freak:

  9. Nice to read this stuff, but i think working longer with projects we start save our time and do some tips mentioned above naturally as it help avoid many problems and save time.

  10. Very good to see these kinds of writeups. It keeps the subject of web standards alive!

    Nothing wrong with px size. As long as you know that these are not absolute and dependant on how a browser handles dpi. OS X is going to drop dpi dependence anyway. I’m so used to using em’s that I don’t give a second thought. Think in cascades!

    I tend to work with rules on a single line. In any case it’s important to place your properties in a consistent way. Ever declared a padding twice? Shorthand notation is handy when writing on a single line.

    I just never liked the clearfix method. I just use clear:both and or overflow:hidden. To hell with IE/Mac. Need legacy support? Then the client will need to pay and sign-off for the extra effort and hacking.

    Keep your specificity as low as possible!!!

  11. Food for thought there, Roger, even if we wouldn’t all follow all of his (or your) advice.

    Personally I tend to use neither pixels nor ems, but the font size keywords: x-small, small, medium, etc. Only if one of these doesn’t suit (which is for headings mainly) do I reach for percentages or ems. I can’t see any reason to use pixels, but maybe that’s because I’m a programmer not a designer - I don’t feel the need to control every last detail of the presentation.

    I don’t do CSS rules all-on-one-line either, but note that Jonathan does it because he finds it easier that way, not because of the bandwidth saving. You just have to go with what works for you (though if what works for you is really cryptic, and you work in a team, maybe you need to work on it).

  12. I had noted in my prior comment that I stick to a set list of class names and IDs as much as I can. But after some microformat study last night, I may be changing some of my class names to mirror the microformat classes. Kill two birds with one stone as they say. I’m completely new to microformat use but found the concept interesting — interesting enough to modify my common CSS practices to accommodate.

  13. October 26, 2006 by Andrew Massey

    It’s interesting what he says about px being the new em’s due to IE7 support. I believe he’s misunderstanding something: IE7 support seems to be the same as previous IEs, what has changed is the way one resizes the “fonts”, in IE7 it’s not only the font which is being resized, but the whole page (like Opera - it’s great, IMO). If one uses the traditional method via the “Page => Text size” menu items you get the same functionality, i.e. no resizing for px.

  14. I put classes at the end of the CSS sheet. Just semantically it seems to be more correct than just put them to the top.

  15. Overall I liked this article, but Px-based fonts are ‘sacrilege’ for a reason.

    1) You are essentially leaving your clients exposed to legal action as you have not made ‘reasonable adjustments’ to make your site accessible.

    You could make separate hacks/rules for IE that specified fonts in sizes they could work with if you are happy to maintain it. I wouldn’t be.

    The majority of people do use IE, and this is compounded by the fact that IE is the only browser with support for Microsoft Active Accessibility which is the enabling factor for screenreaders.

    Last I heard, Firefox were looking into supporting it, AOL/Netscape were asked if they were going to do anything with it and said that they weren’t interested.

    I have just looked at his site on PC/IE7, tried to resize the text, and only the h2 subheadings resize. However, the page zoom feature in IE7 is fine.

    2) px and pt based sizes come from print-based media. The web is not print.

    I would recommend using px and pt sizes for your media=”print” stylesheets, but not for screen media, where there are too many variables.

    The end user could be viewing your site through anything from a cellphone or PDA to a 30” PC screen at 2560 x 1600px resolution.

  16. Yes, I agree with you on nearly every topic above. Especially the floating elements. I ALWAYS have a class called “clearing” that simply has a “clear:both;” declaration, and use it wherever I float an element.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.