Ten Common CSS Mistakes

Avoid these in your stylesheets.

19th June 2006 · Last updated: 21st December 2023


I've recently been tweaking the code on a website designed by someone else, where I spotted several common mistakes in the stylesheet. I thought it would be helpful to point out a list of these and other mistakes in CSS that I've seen before.

1. Redundant Units For Zero Values

The following code doesn't need the unit specified if the value is zero.

padding:0px 0px 5px 0px;

It can be written instead like this:

padding:0 0 5px 0;

The same goes for other styles. Eg:


Don't waste bytes by adding units such as px, pt, em, etc, when the value is zero. The only reason to do so is when you want to change the value quickly later on. Otherwise declaring the unit is meaningless. Zero pixels is the same as zero points.

However, line-height can be unitless. So this is perfectly valid:


Plus you can still use a unit such as em if you want.

2. Hex Colours Need A Hash

This is wrong:


It should be:


Or even:


The above code might be handy for dropping styles into a Cold Fusion document, which uses '#' to denote the start of code to be parsed. Otherwise you will have to remember to add another hash to prevent errors. Eg:


I found that out the hard way when a Cold Fusion document I edited crashed the parser!

3. Condensing Duplicate Colour Codes

Don't write code this way:

border:1px solid #ee66aa;

Duplicate values can be condensed. Write the code like this instead:

border:1px solid #e6a;

Of course it doesn't work for code like this!


4. Avoid Repetition By Condensing Code

Unless you are likely to be changing your code much, avoid using several lines when just one line will do. For example, when setting borders, some people set each side separately:

border-top:1px solid #00f;
border-right:1px solid #00f;
border-bottom:1px solid #00f;
border-left:1px solid #00f;

But why? Each border is the same! So condense it like so:

border:1px solid #00f;

5. Duplication Is Acceptable Using The Cascade

Don't forget that styles cascade (hence the name "Cascading Style Sheets"). So it's okay to style the same element twice, if it means avoiding the repetition mentioned in the point above. For example, let's say you have an element where only the left border is different. Instead of writing out each border using four lines, just use two:

border:1px solid #00f;
border-left:1px solid #f00;

Here, the whole border is styled in one colour, then the left border is restyled with a different colour. The border is therefore being styled twice, but the speed difference is probably immeasurable, and the user will certainly not notice this.

6. Invalid Styles Do Nothing

Only last week I came across code on a site that was throwing up errors over a number of commands. The errors were simple: the author had input a range of styles that didn't apply to the code used. Clearly they would not have been parsed, so the code was pointless.

One example was padding:auto. That style may apply to width and height, but not to padding.

7. Browser-Specific Code

Obviously this will only work in the browser that supports it. Sometimes this is desired, like when you need rounded corners in Firefox, but remember, no-one else is likely to see them. You should aim to design pages that users sees more or less in the same way. I still come across sites that use inline styles to add border colours in a way that only works in Internet Explorer. Don't do it. Your visitors will thank you for it. Or put another way, your site may well look a mess in other browsers.

8. Wasted Space

I'm not sure why, but sometimes designers like to waste a lot of space in their code, by using plenty of unnecessary line-breaks or spaces before and after code. Remember, it'll only make the stylesheet bigger, meaning it'll cost you more in the long run, as your bandwidth usage will be higher. Plus your code will be easier to read and debug with less gaps (there'll be less scrolling up and down needed for a start). Of course it's wise to leave some space in to keep it readable, though some people like to condense everything, leaving no space at all.

9. Specify Colours Without Using Words

Okay, we've all been guilty of this. It's so much easier to define a colour as 'white' or 'red' but it's not a good idea. You're relying on the browser knowing exactly what that colour refers to. For instance, what is red? Is it #f00? Or #f33? Or something else entirely? And what if you use a colour like lightgoldenrod? I've found that sometimes a colour only works in certain browsers. So it's good practice to always specify the colour by its hex code. Eg: use #fff instead of white. I didn't used to do this, so forgive me if you find any older code I've written that still specifies colours by words.

10. Grouping Identical Styles

It's common to see a style applied to many different elements, even though the style is the same. Leave the style off each separate element and style them all in one go later on, like this:

h1, p, #footer, .intro {

It will also make updating the style much easier.

Comments (22)

Comments are locked on this topic. Thanks to everyone who posted a comment.

  1. Russ Weakley:

    I love the artilcle. All the points it raises are clear and relevant. However, some of them (1,3, 4, 8, 10) are not mistakes - they could be classified as "ways to make your CSS more eficient".

    Posted 26 June 2006 @ 8:19 pm.

  2. Rene Saarsoo:

    I agree with Russ, most of what you point out are not really mistakes. Actually I only find nr 2 "Hex Colours Need A Hash" something, that I would point out as a common CSS mistake. Numbers 6 and 7 seem to be too broad compared to others.

    As of nr 9, I agree, that color values like lightgoldenrod shouldn't be used, I can't see the reason to prefere #f00 to red (and there is no ambiguity in what kind of red 'red' is, it's #f00 in all browsers and in CSS specs). Using keywords for color values makes code more readable, using hex numbers makes it less readable.

    But I would like to add some common mistakes I have found:

    1. Using points (pt) to define font-size. Points make no sense in web context.
    2. Using integer value for font-size. Most browsers interpret font-size: 10; exactly as font-size: 10px; at least in quirks mode. This also goes for using integer value for width, height and many other properties, that don't support it. (Besides using 0 of course.)
    3. Not declaring generic font family. Often people just write font-family: Arial; instead of font-family: Arial, sans-serif;
    4. Not quoting long font family names. Quite common one is font-family: Times New Roman;
    5. Using English-English. Ok, that's not a mistake when speaking, but quite a common in CSS are properties like colour, font-colour, background-colour...
    6. Styling browser scrollbar with. It's not in CSS specs and most importantly, there is no point in styling the scrollbar besides pissing off the user.

    (Most of the mistakes described are backed up by data gathered on my research: http://www.triin.net/2006/06/12/

    Posted 26 June 2006 @ 8:19 pm.

  3. alicia:

    10 mistakes to avoid before telling others what to do:

    1. validate the mark-up
    2. validate the css
    3. allow the fonts to be zoomed in ie without the need to put your page in 'accessibility' mode.
    4. make sure your page can hold a 150 t0 200% f0nt-zoom without breaking, or overlappin.
    5. Provide adequate contast so the everything on the page can be read.
    6. Make sure your page makes sense in Lynx
    7. Use a source order layout.
    8. Make sure you have done all of the above
    9. Double check you have done all of the above
    10. Triple check you have done all of the above

    Posted 26 June 2006 @ 8:19 pm.

  4. Tim Lucas:

    For point 5 on cascading, the border size and style is inherited. All you need to override is the color of the left border, which means you can replace the second property statement with the following:

    border-left-color: #f00;

    Posted 26 June 2006 @ 8:19 pm.

  5. David McDonald:

    I agree with Russ, in particular with point #8.

    I deliberately space out my CSS definitions and use line breaks in order to make the CSS easier to read and work with. Yes, it take up a few more bytes etc but it does help with maintenance and understanding the code, especially if someone new has to work with the CSS.

    Posted 26 June 2006 @ 8:19 pm.

  6. Jermayn Parker:

    Enjoyed the article alot.

    Most of it common sense but I have learnt that common sense means nothing with alot of people in regard to web design.

    Posted 26 June 2006 @ 8:19 pm.

  7. Chris Hester:

    Russ, thanks for the link to my article in your post Some links for light reading on the WSG Discussion List. It's got people talking about it here, which is great. I noticed you also linked to an interesting site which can compress your CSS in numerous ways, which I'd like to share here:


    I note it changes colours from #f00 back to red though!

    Alicia, I'm aware of the problems you raise (well, to be honest they have not been tackled yet) but you do realise this site is being output by a blog system, using a template, neither of which I coded? I've already hacked at the CSS a lot. If anything validates right now, I'll be surprised to be honest. It's also very much a work in progress. In fact I hate the design and will probably trash it soon anyway. I will definitely look at all the points you've raised soon. Perhaps I shouldn't have launched the site until I had made sure it validated, and was fully accessible, but I couldn't wait any longer.

    Posted 26 June 2006 @ 8:19 pm.

  8. Aadi:

    Thanks for that, I knew most of them. Another common mistake that I used to do was definining a:hover before a:link and then scratch my head thinking why it's not working. The rule is we need to define it in the order of link, visited and hover (I remember it with Love-Hate word), because of the cascading nature of Style sheets ;-)

    Posted 26 June 2006 @ 8:19 pm.

  9. Chris Hester:

    Just to clarify my point about using #f00 instead of red, although the CSS2.1 spec does show it as a way of setting the colour, if you check the CSS Techniques for Web Content Accessibility Guidelines 1.0, under item 9.1 Colour Contrast it states:

    Use numbers, not names, for colors.

    It then shows H1 {color: red} as a deprecated example. That's why I say not to use names, but specify the exact colour.

    Further reasons are a) what if the browser manufacturer decides the shade of red is too bright on a new type of monitor? What's to stop them turning it down a shade? b) colours such as linen and orange could be any number of shades. Best to be specific.

    Posted 26 June 2006 @ 8:19 pm.

  10. Mike:

    I have to disagree with most of Point 9
    I still have difficulty remembering whether #fff is black or white - much easier for everyone if you just say what you want. As someone else pointed out, most of the colour names are specifically defined by W3C, so no danger there. However I would always use a hex-colour value to allow me to be able to adjust colours when necessary: if red is just too red there is no way to say 'nearly red', but with Hex you can just decrement a digit a little.

    Your Item 10 has spotted a problem, but missed the point. By grouping all of these selectors you have made it harder to maintain - if one of those items needs to be changed, do the others need to change as well? IF they do, then they should all have used the same class to begin with, and there wouldn't have been a problem. IF they don't, then they shouldn't be grouped in this way.

    Posted 26 June 2006 @ 8:19 pm.

  11. Chris Hester:

    I trashed the design. Welcome to the new minimalist look! It took a lot of work, but now hopefully more pages will validate. What I found is that linebreaks I'd put between list items in the code were being transformed into paragraph tags by the system! So there was plenty of invalid code.

    I am still getting to grips with this program, so apologies for any glaring mistakes.

    I have also added permalinks to the comments, along with numbering. Plus I've moved the main post details to the top, so you don't have to scroll down any more to see the link to the comments.

    I will continue to tweak the layout over time. Maybe some gradients...

    Posted 26 June 2006 @ 8:19 pm.

  12. mike:

    Nice list of mistakes. Not sure if this is on purpose or not but your stylesheet is either not loading and giving me a bland styling to your pages, or its not loading any images/colouring. Am I doing it wrong?

    Posted 26 June 2006 @ 8:19 pm.

  13. Chris Hester:

    I took out the colours to redesign the layout. If you can see a black border round the page, and the menu links all on one line, then the stylesheet is loading. I will add some colour soon!

    Posted 26 June 2006 @ 8:19 pm.

  14. Simon Willison:

    Here's the bit of the CSS 2.1 spec that says which hex colours should be used for colour names - it lists 17, and using those names is completely safe.


    I'd love to know why the WCAG guidelines warn against using colour names.

    Posted 26 June 2006 @ 8:19 pm.

  15. Chris Hester:

    OK, that last design sucked. I have restored the template designed by Simon Collison. I have spent a long time updating it too. I was wrong to take it out.

    Posted 26 June 2006 @ 8:19 pm.

  16. Andrew:

    It's not really my style to critique, but since you're talking about mistakes and your site design...

    Perhaps using purple for unvisited links and using blue for things which are not links aren't the best ideas.

    Posted 26 June 2006 @ 8:19 pm.

  17. Chris Hester:

    I think you need to clarify that for me. On my screen, the links are blue. Only the post titles are purple-blue. Visited links are red. What do you mean by using blue for things that are not links? Do you mean the examples of code?

    Posted 26 June 2006 @ 8:19 pm.

  18. Andrew:

    I suppose #339 straddles the fence between the blue and purple families. Your h3 elements (which are not links) are vividly blue. Thus, your unvisited links (#339) look purple in context (to me, at least.)

    For the record, I wasn't really confused on this site. A less savvy user on a different type of site could be, though. I guess I prefer to tread safely in the "don't make me think" end of the pool.

    Posted 26 June 2006 @ 8:19 pm.

  19. Tom:

    Well... I'm curious what your program code looks like. Most of the points go directly against one of my #1 programming rules: be unmistakable.

    Posted 26 June 2006 @ 8:19 pm.

  20. Danjo_Hart:

    Again, like others who have noted it, I have to chime in about the 0px thing.

    Setting padding for a div like:

    padding: 0px 4px;

    Is NOT a mistake, and in fact I argue it is more frustrating to see other coders write:

    padding: 0 4px;

    It is unclear, less attractive, and therefore less consistent.

    To each their own I guess, but please stop calling it a MISTAKE.

    Posted 26 June 2006 @ 8:19 pm.

  21. Chris Hester:

    I disagree. 0px is a mistake. It means nothing to declare a zero value by adding a unit such as px. What is unclear about padding: 0 4px? The first part clearly states "apply zero padding". Why would it be clearer to say "apply zero pixels of padding"?

    It is unclear, less attractive, and therefore less consistent.

    It's more attractive to me, even easier to read. Plus it uses less bytes.

    Posted 26 June 2006 @ 8:19 pm.

  22. mike:

    It is bad because it encourages others to break your coding: if you have the entire site written with ems's and percentages, then when that padding needs to be changed, a later author needs to decide what units to use, and will likely choose pixels - if you leave it as 0em then it is obvious what units you are using.

    Posted 26 June 2006 @ 8:19 pm.