My Worst CSS Mistakes

By  on  

I've always taken a lot of pride in the fact that I've taught myself most of what I know. It started when I was 13 and taught myself HTML, then CSS, then JavaScript, then PHP, and the process continues today with MooTools, jQuery, and whatever else comes my way. I'd be lying if I said I didn't learn some things the hard way though. Have a chuckle at some of my past CSS mistakes.

* { font-size:11px; }

Setting the font-size property within the "*" selector was a huge mistake on my early websites. Nesting tags would result in a reset font-size, so in some cases I had to duplicate font-size declarations inline. Painful to look at old sites with this.

<p class="bigger">I wish you would <a href="https://davidwalsh.name" class="bigger">click here</a>.

* { color:#000; }

Another case of placing a property within the "*" that I shouldn't have. I'd again need to duplicate inline-styling efforts when nesting tags.

Long CSS Declarations

When I first started with CSS, I didn't know any shorthand CSS. Unfortunately, my classes would end up looking like:

.my-div { margin-right:20px; margin-left:20px; margin-top:3px; }

Shorthanded declarations have made CSS life much easier.

Long CSS Colors

When I see some of my old stylesheets, they're full of long color declarations, like:

.my-div { color:#000000; background:#ffffff; border-bottom:#ff0000; }

Of course, the above should look like:

.my-div { color:#000; background:#fff; border-bottom:#f00; }

Multi-Line CSS Declarations

Some of my old stylesheets look eight miles long. There's a huge difference in maintainability between a 10 lines and one:

/* too long */
p
{
	font-size:12px;
	line-height:19px;
	color:#999;
	margin:0 0 5px 0;
	padding:0 0 15px 0;
	text-indent:20px;
	font-family:arial, verdana, sans-serif;
}

/* much better! */
p { font-size:12px; line-height:19px; color:#999;  margin:0 0 5px 0; padding:0 0 15px 0; text-indent:20px;  font-family:arial, verdana, sans-serif; }

So those are the ghosts in my CSS closet. What CSS practices do you regret today?

Recent Features

  • By
    Introducing MooTools Templated

    One major problem with creating UI components with the MooTools JavaScript framework is that there isn't a great way of allowing customization of template and ease of node creation. As of today, there are two ways of creating: new Element Madness The first way to create UI-driven...

  • By
    Create a CSS Cube

    CSS cubes really showcase what CSS has become over the years, evolving from simple color and dimension directives to a language capable of creating deep, creative visuals.  Add animation and you've got something really neat.  Unfortunately each CSS cube tutorial I've read is a bit...

Incredible Demos

  • By
    jQuery Link Nudge Plugin

    A while back I debuted a tasteful mouseover/mouseout technique called link nudging. It started with a MooTools version and shortly thereafter a jQuery version. Just recently Drew Douglass premiered a jQuery plugin that aimed at producing the same type of effect.

  • By
    MooTools CountDown Plugin

    There are numerous websites around the internet, RapidShare for example, that make you wait an allotted amount of time before presenting you with your reward. Using MooTools, I've created a CountDown plugin that allows you to easily implement a similar system. The MooTools JavaScript The CountDown class...

Discussion

  1. Absolute positioning! It took me a while to get to grips with floating so I would position everything absolutely – we’ve all got to start somewhere though!

  2. Miguel Palazzo

    Hey David! Yeah, I think those are common mistakes of many devs out there, pretty sure of that hehe :D I used to declare common font-family and font-size for my entire document on html {} not on body {} which doesn’t work quite well on most browsers hehe.

    I still use multi-line CSS declarations! I’m nost ashamed of that, it is simple :) I use in most of the cases 2 cloned CSS stylesheets. One, the good looking, with identation and such, for development purposes only. For production, I just use YUI Compressor which does a remarkable job not only for JS files but CSS also :D Clearing it all, making the whole stylesheet a one-liner. It is simple, I use my JS well identated and blah blah blah, same for CSS, cuz if any other developer or designer at office can fix anything before it goes live, they can.

    Everything else, heck, I found out like 2 years ago I could use only 3 characters for generally paired colors, like #FFF = #FFFFFF but just in case someone else doesn’t know it, don’t you ever think about constraining that way if you have colors like #F8FFF1, don’t dare about putting it #F8FF1, it won’t work :D

    Interesting article :)

  3. Иван

    You are not serious about the one-line declarations, right?

  4. @Иван: Absolutely! I cannot stand scrolling 1000 lines of CSS code. One-liners, for me, are so much easier to read.

  5. We all do mistakes! In your case there are no mistakes! You are just wasting precious space :).
    Another tip: font-weight:bold better font-weight:700

  6. The last one is completely a matter of choice though. Completely.

    The rest are all valid points though.

  7. Rich

    @vladimir “Another tip: font-weight:bold better font-weight:700”

    I don’t think that works across all browsers.

  8. The last one I guess is a matter of choice. I find it more easy to have each declaration on a new line and yes, inevitably much more lines. But if you group styles in the right way it is always easy to go through quickly your entire style sheet.

  9. @Rick: I think font-weight:700 is working on all browsers. There are some problems with 500,600.
    See:
    http://www.quirksmode.org/css/tests/iewin_fontweight.html

  10. lowell

    i’m a ruby/rails developer, not a designer like most of you.. the thought of single line declarations/code scares the crap out of me lol.. css, like any kind of code, gets messy quick.. try using the pico indentation style, it eliminates dedicating a whole to a brace like the classic c/k&r style does..

    so, turn this:
    p
    {
    font-size:12px;
    line-height:19px;
    color:#999;
    margin:0 0 5px 0;
    padding:0 0 15px 0;
    text-indent:20px;
    font-family:arial, verdana, sans-serif;
    }

    into this:

    p
    { font-size:12px;
    line-height:19px;
    color:#999;
    margin:0 0 5px 0;
    padding:0 0 15px 0;
    text-indent:20px;
    font-family:arial, verdana, sans-serif; }

    looks way cleaner in textmate

  11. Just a suggestion on your last item. This could actually be cleaned up a bit more rather then just removing the whitespace.

    p {font: 12px/19px Arial, Verdana, sans-serif;color: #999;margin: 0 0 5px;padding: 0 0 15px;text-indent: 20px;}

    When you have all 0 but one on a padding or margin you only need to set the top, left/right, and bottom – which can be done in 3 instead of 4. You can also combine the font-size and line-height in the font declaration.

  12. @All: I consider these MY mistakes. If you use multi-line declarations, all the power to you. In my development, I consider it a mistake.

  13. Mike

    If these are your biggest css mistakes, you must be pretty awesome at css.

  14. Josh

    IMO the worst CSS mistakes are the ones that make your code hard to maintain in years to come. Combining attributes into a single line might be ok for short declarations or for you, but think about the next guy who comes along and has to edit that code.

    You can argue that saving white space will speed up rendering but if you use external css files and send the proper cache headers your users will make up the difference by using a local disk cache of your styles instead of another http request.

    Coding with indentation then using a compressor for production code is probably the best idea.

  15. Aaron

    I think my worst mistake so far was applying fonts to individual parts and not to the body tag as the base font. Oy!

  16. I still do multi-line comments too. I avoid huge CSS files by have multiple CSS files. I avoid having multiple network requests by concatenating them together on build (except in dev mode in which case I have them broken apart still)

    Also, I intend to keep using full colors. It’s much easier to read at a glance in my opinion.
    Besides, I minify all my CSS anyways when I build so it’s going to reduce those colors where available anyways.

    As far as shorthand margin/padding/etc declarations, I’ll only do this:
    margin: top right bottom left;;
    I’ll never just use three or two because it just adds confusion when reading the lines, especially for others who may not know what the priority order is.

    Again, no need to worry about saving space since the compressor takes care of all that for you.

    So wow, aside from the wildcard ‘mistakes’, I disagree with most of what you said :)

  17. Re: Multi-Line CSS Declarations, there’s also a huge difference in maintainability when you’re running diffs in large projects over teams. Single line declarations will kill you (and so might your peers). I’d recommend (like others above) not to prematurely optimize, and flip the switch on some sort CSS compressor only after you’re ready to deploy. Granted this is all moot if you’re the only one working on the project, so use whatever works.

  18. Juan Carlos

    I vote for one line as david point out, it is faster to find de rules, but I keep declarations organize. That also important!

  19. hehe i I’ve done them all

    mine probably was writing out margin-left, margin-right, margin-top, margin-bottom,
    took me so long to get myself to think margin: x x x x; Writing shorter CSS is not just a good thing in case you need edit next time, but if you are working on big applications with about 3000 lines of CSS. File can become very hard to edit.

    Do you use shorter version for declaring font features in css. like combining font-family, font-size, color, font-weight and such?? That is my next step in making shorter CSS and clean code.

  20. Dan

    oh how these ring true in my books.
    Great article.

    re single line css, I am in the same boat as you – and for those who don’t use this method, fair enough its all personal preference.

    I personally write my source on one line because it helps me drastically reduce my time spent on maintenance and updates and just generally working on a project, because as David put it – “I cannot stand scrolling 1000 lines of CSS code”

    you may say “do a search to find what you want” – and I ask you “are you always looking for something in particular or do you sometimes scan to pick up elements and or make changes?..”

  21. Brian McKendrick

    Not trying to be a d!ck or anything – you need to push yourself a little harder. While it’s important to take pride in your accomplishments – those types of individuals typically will take greater ownership in projects/tasks which is usually evident in the results.

    But learning HTML, JavaScript, MooTools, etc is not really all that difficult – you shouldn’t be satisfied that you mastered a very basic toolset.

  22. Lonny

    It’s always funny reading about how bad “Multi-Line CSS Declarations” are. I’m a software developer for 15 years now and no one every came up with the idea “My source code file is too long, I’m putting all statements of a function in single line.”

    Long lines are harder to read than short (maybe that’s the reason there are no “widescreen” books and news papers still use narrow columns for articles)
    Long lines don’t fit on the monitor. So you have to scroll (horizontal scrolling is a pain, our do you horizonzal scrolling with the mouse wheel) or activate virtual word wrapping, which reduces readability because indention gets lost.
    There’s a thing called “code folding”… strange nobody mentioned that yet
    Good editors have an outline view which displays only the structure without the implementation
    A source code line length limits of 80 or 100 characters is still common

    But that’s just my opinion :) and maybe of another two or three software developers worldwide….

  23. Okay, I’ll add my vote to the last one. I prefer to have vertical columns to read rather than scroll to the right/left, so it’s obviously a personal choice.

    In development I keep my code blown all the way out.

    However, I keep my reset/base stylings on one line (because they seldom need debugging), and the end goal is to minify the CSS/JS beyond shorthand (so eliminating white space, condensing down to one line, etc.)

  24. @Brian McKendrick: I’m never satisfied and I continue to learn more today — not an accurate portrayal of me.

  25. Single line declarations are amazing!!! I have used them for a few years now and hate the other way. One way I’ve kept them a little cleaner is by writing them in alphabetical order.

  26. .. by writing them in alphabetical order.

    Wow, that is wrong on so many levels :)

  27. @Seth: I tried to do that but it’s way too hard. I put the most variable stuff on the left.

  28. Regarding multi-line CSS declarations: I am sorry but I can’t see the advantage. If you put everything in one line the file ist shorter but you are not scanning the long line as fast as you do with the short ones. That’s the reason we don’t write HTML or PHP code in one line either.

    As for the length of the CSS file I recommend using a tool like CSSEdit that lets you group your css and organize it properly:

    http://macrabbit.com/cssedit/features/editvisual/

  29. I definitely prefer the cleanliness and and clarity of keeping each declaration on a single line. I’ve considered the enhanced tracking multi-line declarations provide when used with version control tools. In the end, catering to my own human ability to scan a compact screen full of CSS for patterns and specific items is more important.

    However, I do err on the side of long CSS declarations for the sake of the novice who inherits my code. I always prefer readability over compactness. Give me a descriptive 39-character class name over .col3 any day!

  30. I started writing mine in alphabetical order once I was handed someone else’s CSS that had margining declared three times in one line.

    Oops.

  31. One liners are great if they aren’t too long and you have to scroll horizontally to see what’s what.

    Otherwise, all good points and things for novice CSS writers to avoid.

  32. xpix

    I got 2 questions:

    Should I use em? I never use them now.
    do you use resets for boxes Eg #myleftbox *{margin:0;padding:0}?

    Thx

  33. I think you should use EM but only for font size. See IE6 does not let you re-size PX font size which means if your user has poor eye sight and they like to make their browser font bigger they can’t. PX can be re-sized by Firefox and IE7.

  34. xpix

    Then I guess I’ll stick with px. I don’t support IE6 anymore unless requested. I just try to make it look good.
    Thx Boris

  35. I try and avoid px at all costs. Fonts, margins, padding, it’s all EM for those.

  36. Chris

    I’ve just gotten my head round ems, all thanks to the 62.5% rule… one of the best tricks I’ve ever come across!

  37. V1

    I just build a big ass css document with comments and shit, and than minify it to a single lined css.. Saves a few KB here and there. If u can optimize i dont see any reason why not to :)!

  38. I have to disagree with everyone who puts CSS code into a single line.

    Its messy, unreadable and keeps me awake at night!

    If your worried about load times just shrink your CSS before uploading.

  39. Мартин

    short line declarations aren’t a solution at all … i still don’t get why people think it’s better?

  40. @mkjones, thank you for that link, I have run it with my current project that has a big CSS file and it decreased it by 27%. Through I fear if someone else tries to edit the file they might have some difficulties because it was compressed.

    @Martin, from my personal experience I don’t write all CSS in short line. I simply combine relevant CSS like width and height in one line and font, color, font size, text decorations in one line.

    The main concern is that if you work on large applications where CSS can have up to and over 2,000 lines others who work on the project might have hard time using your CSS.

  41. Through I fear if someone else tries to edit the file they might have some difficulties because it was compressed.

    You should only ever compress for production.
    In fact I tend to have the actual development CSS/JS sit right alongside the ‘compressed’ versions.
    Then just a simple flag controls whether the development or production files are used. In production the default is the optimized obfuscated minimized files and during development, the development files. This gives you the best of all worlds, including the ability to point someone at a special URL or something that will dish out the development files (even on production) in order to be more accurate firebug line numbers or something.

    The main concern is that if you work on large applications where CSS can have up to and over 2,000 lines others who work on the project might have hard time using your CSS.

    Why does everyone keep raising this point?
    The solution to this problem is not to start putting things on the same line, it’s to break apart the CSS into multiple files.
    If you have thousands of lines in your CSS files, they’ve got to be describing huge scopes of your application that could easily be divided into smaller and more targeted files.

  42. Kirbo

    This is how i like to do my css
    Multi-line css, heavily indented and make 1 line comments to divide different sites/elements, so others (other developers at my job, IF they had to change something in css, if im not around) can easily find like “Where’s the styles for Shopping cart” for example.

  43. Multi-line CSS is really horrible to look at. I find that it is much harder to scan for stuff when it’s multiline and that if you have #example on a single line it’s much easier to actually GROUP classes etc. together in chunks – a thing you can’t do at all with the multiline coding style. It enables to have like;

    /* standard form */
    form.standard {color:#000; background:#fff; }
    form.standard input {border:1px solid #ccc;color:#999;}
    form.standard form input:focus {border:1px solid #000;color:#333;}
    
    /* stuff */
    #stuff a {color:#777; text-decoration:none; }
    #stuff a:hover, #stuff a:focus {color:#000;border-bottom:1px solid #000; }
    

    Point made?..

  44. Oh… and btw – if you’re so worried for long lines do a secondary grouping;

    /* main */

    container {position:relative;width:950px;margin:auto;}

    container {color:#000;font-size:12px;font-family:”trebuchet ms”, helvetica, sans-serif;}

  45. I try to keep short css-code in one line, if it’s more than a few selectors I write ’em line per line.
    Also, use tabs, e.g. 1 tab for ul, 2 tabs for ul li, 3 for ul li a, so the inheritance is more obvious when editing the css-code. This is a practice I only just adopted, seems to work better, but time will tell.

    T.

  46. I prefer multiline CSS declarations, I think they are much more readable and easier to understand than multiscreen CSS declarations in one line.

    And what do you think about setting the margin and padding properties within the “*” selector? I find it very useful.

  47. yep I am also a multi-liner! UNLESS there is only one property… but I think of it this way, with one liners you have to scan up and down and then sideways. Multi-lines you just have to scan up and down :P I use nusphere which allows code folding, so a lot of the time I will fold large portions of my css if I am not working on it. Problem solved!

    Looking back on some of my very first projects, I think my biggest mistake was using absolute positioning… FOR EVERYTHING… and of course I had no idea what position relative was so everything was positioned to the browser window LOL… I had no idea what float was either so that really limited what I could do. Thank gosh for books :P

  48. Nice post!

    Although I personally think ‘Multi-Line CSS Declarations’ is okay because although the stylehseet can become major long its much easier to find the bit you want to change :)

    Stu
    http://selfconclusion.co.uk

  49. I don’t agree at all with people in favor of multi-line. I believe most of you cannot be CSS experts, if it’s too hard for you to read a single line of CSS with several properties. These properties belong to one selector, and there is no particular order, unless your specifying properties multiple times (which you shouldn’t). If you’re appalled by multi-line I bet you’re a programmer.

    There is a huge difference with code (javascript, C, PHP) where the order of execution is extremely important.

    Folding? Nonsense, another programmer’s attitude. CSS consists of a non-indented list of selectors. There’s no hierarchy, so what’s to fold?

    I recommend using a good editor though. TopStyle rules, it’s a CSS editor, not a code editor.

    In short, CSS is not a programming language, so stop treating it like one. (BTW: I am a programmer, not a designer).

  50. Yea, I actaully think that if you have single line declarations it would be a pain to scroll all the way to the right – not to mention all the way left again!
    I’d much rather only being able to scroll up and down, not up/down/left/right :P

    Much like that rule of never have horizontal scrollies on web pages :)

    But yea, personal preference – just voicing my opinion that’s all :D

    Ah, the days of having a 25.5″ screen would solve our problems won’t they! A few more years and people will be saying: “Man, you only have a 25.5″ screen? Keep up with the times and get a 30″ like everyone else!”

  51. As a “classic” example of beginners in CSS mistakes you can check my newly updated page(s) from the archaic HTMl+tables to XHTMl+Css
    at:
    http://www.geocities.com/mauroj2/index.html

    I am still finding the “weird” behavior of my pages,especially on IE 6 and above, notice the misplace side menu!
    my main page CSS can be seen here:
    http://www.geocities.com/mauroj2/newstyle.css

    any pointers to improve the structure of the page?
    I am still learning the curve of proper CSS
    Thanks to all.

  52. Agree on all points, though… I didn’t know about the nested tags with *, I try to actually using it as a selector anyway.

    I especially agree with you on one line declarations. Very rarely (never) do I find people who agree, most people think it’s easier to look at it on multiple lines. It might be easier to find a property a second faster (which can even be fixed with alphabetical order)… but 1 line declarations in combination with tabs is a great way to mimic a DOM tree in CSS, and makes it exponentially easier to work with.

  53. Ah man, this article has brought back some memories of my early CSS adventures lol! Nice article :-)

  54. My neighbor and I were just debating this specific subject, he’s usually in search of to prove me incorrect. Your view on this is nice and exactly how I actually feel. I simply now mailed him this website to show him your own view. After wanting over your web site I guide marked and will probably be coming back to learn your new posts!

  55. Grok

    I think you’re doing it wrong.
    /* just right – my way: group props by kin, color / font & type / block position */
    p {
    color:#999;
    font-family:arial, verdana, sans-serif; font-size:12px;line-height:19px; text-indent:20px;
    margin:0 0 5px 0;
    padding:0 0 15px 0;
    }

    /* much better! */
    p { font-size:12px; line-height:19px; color:#999; margin:0 0 5px 0; padding:0 0 15px 0; text-indent:20px; font-family:arial, verdana, sans-serif; }

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!