Are You Making These 10 CSS Mistakes?

Working with CSS can seem like a constant battle. Browsers are always changing they way they read the code (*cough* Internet Explorer *cough*), and it seems that there are lots of tiny little CSS “gotchas”. While it’s an incredibly powerful language, it can easily be used incorrectly, which will doom your development to a lifetime of imperfections.

1. Ignoring Browser Compatibility

This is probably the number one problem with web development, as you have to have layouts that look the same, no matter what browser the site visitor is using to navigate the page. This fact may sometimes seem like the bane of your existence: there are fundamental differences in the way Internet Explorer renders a page, versus Firefox. While it’s not as bad as they used to be, there’s still quite a difference between browsers.

It’s easy for web developers to layout the page in their favorite browser and not worry about how it looks in other major browsers, as you most likely won’t see the differences. (I’m a major offender of this. I’ll sometimes design the site in Firefox and forget about checking in IE until after it’s done!) While there are some tried and true methods to help safeguard your layouts for different browser rendering, the best way to ensure everything looks constant is to just use Browsershots. Browsershots gives an accurate snapshot of what your site looks like across many different platforms and browsers, allowing you to make sure nothing looks funky in a browser.


Photo by lazlo-photo.

2. Not Accounting for Smaller Browser Resolutions

While a good number of us web developers have large computer monitors–and are quite proud of the fact–a good portion of the visitors to your site might not. You can check your analytics programs to see your visitor’s browser resolutions and how widely they range (Google Analytics does this wonderfully). However, there is a world of difference in the way a design looks in an 1024×768 resolution as opposed to a 800×600 resolution. It can make a beautiful design almost useless.

I recently came across this realization as I was tweaking the design for Trendfo. A large chunk of the visitors to the site were using smaller browsers causing an image to partially block some ads, giving me less clicks and ultimately less revenue from the site.

Accounting for smaller browsers means that all of your visitors are happy and finding the information they need.


Photo by Petteri Sulonen.

3. Not Considering Frameworks

If you’re developing a CSS layout from scratch, you might want to ask yourself why. Just as nothing is new under the sun, the same is true with CSS. There are plenty of CSS frameworks out there like Blueprint framework and the 960 CSS Framework. These are created to help you make bulletproof layouts, without having to start something from scratch. These layouts have cross-browser compatibility and have been rigorously tested. Really, unless you’re doing something totally radical that needs pantloads of custom code, just use a CSS framework.

Why reinvent the wheel?


Photo by nestor_galina.

4. Not Utilizing Generic Classes

It can be quite easy to not think about the future when we’re developing websites. Often times we’ll name our CSS classes something different each time we develop a site, as opposed to making a simple CSS class that we can reuse repeatedly throughout our design, without having to dig up what we used before. This will ensure that our site design remains constant throughout the changes of a design.

You might use a generic class like:

(Editor’s note: the double ‘rights’ are the result of a bug in our code viewer, correct code is of course .right{float:right}.)

.right{float:right}

To keep things floating in the right direction when you want them to. So you could style DIV ID like:

I usually use at least three generic classes when I’m building a site design:

	.clear{clear:both}
	.right{float:right}
	.left{float:left}

Photo by cnynfreelancer.

5. Not Validating the HTML

I bet you didn’t know that validating your HTML could also affect your CSS, did you? Well, it can. First and foremost, you can’t validate your CSS until you have valid HTML. Secondly, there are many instances that your HTML could be causing your problems, instead of your CSS. Often times we think that our CSS altering the layout when in fact it’s a bit of malformed HTML that’s making the layout funky. An unclosed DIV here, a mislabeled CSS class… it could be anything. Make sure that your HTML checks out before you even try to diagnose a CSS problem.


Photo by Focal Intent.

6. Not Validating the CSS

I used to constantly bother a friend for help with CSS problems as I tried to wrangle my designs. He’d patiently ask me every time “Does the CSS validate? If not, what are the errors?” It wasn’t long before I learned to validate the CSS before I’d ask Thomas for help later on, and usually validating fixed the problem for me.

If you have valid CSS code, you’re much more likely to have a CSS that is much more compatible across browsers and is less likely to break.

7. Using Mammoth Background Images

Often times new designers will use oversized background images in their layouts. For example, using a 3,000px X 5,000px background image to account for any possible browser size. Instead of using a really big image, they could be using a really tiny repeating image with a touch of CSS magic. The difference is huge: Instead of loading a 200kb image, you could load an image only a few bytes in size and have the CSS repeat it across the background.

If you have a background image that is very large, you’re losing two ways:

  1. It means using unnecessary bandwidth
  2. You’re making the visitor wait longer for the image to load

Sometimes large background images are unavoidable, especially with the recent trend of designing illustrative web layouts. However, using repeating images or solid colors in the background is a much better practice.


Photo by Petteri Sulonen.

8. Using CSS For Everything

When people first learn about a technology, they become excited about it and want to use it everywhere, even when it can actually go against what will work best for the project.

As web developers we can sometimes get caught up in wanting the technology to do something advanced and specific, when in fact we can use a different technology much easier. For example, sometimes it’s much easier to use a table to organize data than it is to make complicated CSS-based layout with floating DIV’s and the like. We have to remember, the reason why we use technologies like CSS is because it should speed up development time. When it starts to slow us down, then maybe we’re going a little overboard.


Photo by Timm Williams.

9. Using Inline CSS

This is a cardinal sin for web developers, and it happens more than you’d like to know. If you’re building a design, you’ll almost always want to keep your CSS and HTML separate. This ensures that when (notice I didn’t say “if”) you decide to change the site design, you won’t have to dig through the HTML of each layout and find the rogue CSS attached to an inline element.

Instead of using this:

link

You should move the style business to an external style sheet like this:

link

Inline CSS should almost always be avoided. It’s easy to use and great for testing, but other than that you probably wouldn’t want it in your production code.


Photo by nestor_galina.

10. Using Too Many Files

Have you ever seen a design with 12 different CSS files attached to it? It’s a nightmare for anyone trying to make changes to your layout. Not only that, it slows down the time processing each file, as the browser has to make a request for every single one. It’s better to use a simple CSS schema that uses 1 or 2 files. The time spent parsing 12 files versus a single file is quite significant. Not only that, you’ll save the next guy who has to make changes on your layout a lot of hassle.

Nobody wants to open 12 files to make a simple, site-wide change!


Photo by lightmatter.
  • Subscribe to the NETTUTS RSS Feed for more daily web development tutorials and articles.

Glen Stansberry is a web developer and blogger who’s struggled more times than he’d wish to admit with CSS. You can read more tips on web development at his blog Web Jackalope.

Liked this post? Vote for it on Digg below. Thanks!


Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • http://mattlohkamp.com matt

    dude, way to marginalize semantics – on #4, you should use classes that succinctly describe the content of the element they apply to, and on #8 you should never use tables for anything other then tabular data. what you’re saying boils down to, “do it the right way, until it gets hard, and then do it the wrong way so it’ll be easy.” Which is totally wrong – you need to always do it the right way, because otherwise, what’s the difference between you and your client’s nephew who took an HTML class in highschool and can use FrontPage to whip up a new site for a fraction of your quote?

  • http://www.chrisinthebox.com JustChris

    @honour chick
    Inline CSS is a necessary evil for e-mail. I had to convert a couple PSDs into HTML e-mails for a client’s campaign and its campaigning software strips style tags and everything outside the body tags. Different e-mail clients treat CSS differently, so unfortunately you do have to resort to the harder-to-code inline CSS.

  • BobH

    God, I hate people who feel the need to write, “These tips are fine…for *beginners*.” How obnoxious.

  • http://www.theamarugroup.com Rob

    All great tips, never used CSS frameworks before, maybe I’ll sit down one day and take a look into it.

    Validating XHTML/CSS and cross-browser testing are key, and I’m starting to use generic classes more and more.

    Keep these articles coming!

  • Max

    Ah, the words of the elitist web designer.

    Go do some math. A small CSS file from scratch is often way smaller than a framework. Using the framework can be as bad as using a mammoth background image.
    Likewise, pulling everything into one file, when not everything issued on the current page is a waste of bandwidth.

    Also, exactly which browser are you referring to when you say it parses 12 files much less efficiently than 1. Have you done benchmark tests to prove this? Can you cite your data? Do you even know the algorithms browsers use to “parse” CSS?

    Finally, the network efficiency of 12 files vs. one depends a lot on the actual TCP/IP routing, packet size, etc. 12 parallel requests for 1400 bytes might be faster than 1 request for 12 *1400. So long as your CSS file is smaller than the smallest packet size on the specific route between host and client, there is likely no loss there.

    In a nice little, idealistic, academic world, your points all make sense. But you gotta know when to break the rules, and you gotta actually know what browsers and network do before you start spouting off as if your answers are the only answers.

  • http://www.thepatchbay.com Troy Dalmasso

    Your use of Burning Man images for commercial purposes (you sell ads on this page) is a violation of your license.

  • http://imbuzu.wordpress.com Buzu

    not one, I’m really strict when it comes to developing a site. Though I use generic class and Ids in a different way. I’d never use a right or left, simply because that describes the position of the element. A well named class should describe the content of the element, so that when I want to re design the site, I don’t have to worry about changing all my right classes to left just because I want to put my left column on the right side of the window.

    Nice article, and nice tips. Validating it’s important, and you’re one of the few I have read that mentions it.

  • http://www.freshivore.net Vince

    @JustChris

    Exactly, for maximum compatibility in emails use inline css and nested tables. It absolutely blows but it’s what you have to do thanks to clients like Outlook 07.

    no support for background-image, background-position, background-repeat, width, height just to name a few…

    Not a day goes by that I don’t want to punch everyone at MS in the face.

  • http://imbuzu.wordpress.com Buzu

    no, no I’m making one, not using frameworks. I’ve never tried them, but I don’t like frameworks. Maybe I should give them a try. I might like them. (I don’t really thing not using them is a mistake, but since you mention it as a mistake, then I’m making one jaja)

  • Rasmus

    Several of your points seems very flawed and – to me at least – it feels like you only do small or medium projects.

    1-2 CSS files? Come on, that’s just plain wrong. Talk about a maintenance nightmare. I don’t mind opening a few ekstra files, if that gives me a better oversight. That and making sure comments is added perfectly. If you throw in a table of contents when you’re at it — that’s all for the better.

    When you compress your JavaScript and CSS files before deploying, all of your mentioned benefits is achieved without comprimising an open and friendly dev environment.

    - and please don’t get me started on CSS frameworks. They are excellent for newcomers and as a basis to start a learning process, but in practice they are completely useless. I mean, is CSS really such a demanding and time-consuming process, that you have to use a framework? Really? If you answer yes to this question, I highly suggest that you start dusting off your abilities – and stop using these so-called “frameworks”.

    It feels like you assume too much :)

  • Pingback: Web Design Resource List « Brenda Kato’s blog

  • Tim

    As some have said before, using classes name fright and fleft are not semantic. I don’t see how it is a mistake not using these. It is not worse than using inline styling.

    Also, on the point about large background images. You mentioned that large backgrounds would keep the user waiting? I was under the impression that css background images load separately from the content and therefore would not keep the user from reading the content. The site just wouldn’t look “right” at first.

  • jason

    @reader(above) Dood, chill down man. Do you feel better now that you’ve insulted the author and half the posters? Weak.

  • Mocoso

    This list didn’t told me anything new. Anything “advanced”? What’s with the pictures? @_@’

  • Phil

    I don’t agree with using the CSS frameworks. They are great in some instances (such as news pages, yahoo, things with lots of separate areas), but for you general site it’s easier, and more satisfying to create your own.

    Cross browsers is always a chore, however there is light at the end of the IE6 tunnel – many ‘big sites’ (facebook being one) now put little messages up telling people to upgrade. Again though, Google Analytics will tell you what people are looking at your site with, if you have an abundance of people from the past looking at your site, make sure it works!

  • yhv

    I was hoping for something more … useful? Like gzip, camel case or not, backgrounds against borders etc … Sorry, but most of the people learn those things within their starting period.

    Why am I even posting this?

  • http://www.gimnastas.net Calítoe.:.

    Yes, what some people here have been saying is true: few designers design for 800×600 screen resolutions BUT, at least in my case, 10% of my visitors use that screen resolution and I do think it’s a lot. It’s easier for me to make a elastic or fluid layout (so far I’m stuck with a 800 px width one) rather than tell them that they are retarded, because they are not.

  • http://woofandwarp.com Arno

    Here’s a good read about not using underscore in id and classes.

    https://developer.mozilla.org/en/Underscores_in_class_and_ID_Names

  • http://snedekerdesignz.com/blog/ Craigsnedeker

    Awesome article!!

  • http://www.melforrest.com Mel

    So many points in this article are a total load of crap! I don’t know where to begin.

    CSS Frameworks encourage bad practice, they are bloated and are full of presentational as well as just totally meaningless class names. The add a high level of complexity to building web pages that you really don’t need.

    You should never use presentation class names like left and right, they are no different to using class=”blue”. Class names and ids should relate to structure and content of the document and not a visual representation.

    I will agree with point 10, too many css files become a nightmare to maintain.

    Point 2 – account for smaller browsers really depends on your audience. It’s a little pretentious to just make the claim all sites should account for an 800×600 resolution.

    Big backgrounds are fine, again this is something that really depends on the audience, yes web designers / developers should make an effort to reduce bandwidth, but to outright say large backgrounds a wrong is completley obnoxious.

    Yes inline css is bad, but your example is also stupid, we know its a link already you dont need to give a link a class name called “link_style” thats just as bad as which i’ve also seen people do. It is good practice to minimize class names and use the hooks you already have available to you, structure your document properly and don’t litter it with bull**** class names.

  • http://mokshasolutions.com Moksha

    nice things to remember thanks

  • xyz

    Yet ANOTHER POINTLESS INTERNET LIST full of obvious and ubiqutious information. Anyone over 13 that would actually find this list informative or helpful has no business building websites.

  • http://jivebay.com jive

    While I understand your point about using generic classes, often times it’s not a good idea to unless they are symantic. Using .rightright is not a good idea, however using .cutline or .preview or .minor would be acceptable.

    • http://twitter.com/nicluciano Nic

      Hm, I understand what you’re saying Jive- but I’m not sure it applies here. .right is a semantic description of it’s function. When applied with other class names it starts to make more sense; “right panel” or “right sidebar”.

  • Pingback: 10 Common CSS Mistakes | Blake's Tech Blog

  • http://spongeproject.co.uk Rob Mason

    Are these really CSS mistakes or general design mistakes?

  • john nocrapish

    It’s a shame.

    Look at your own source page. There’s a table to display ads. Your markup is full of class=”someclass”.

  • http://www.speedstrip.com Angry Designer Fag

    Top CSS mistake of all time: Reading articles like these, which are full or either DUH or FAIL.

  • Radek

    Useless article

  • rock

    Great. Yet another article from someone telling everyone how to make their web pages. Seems like I see this sort of thing about 50 times a week at as many websites. KMA

  • http://joenote.com Jordan

    I disagree with point number 3. There is no need to make your site accessible to “all” to make it effectual. One must merely consider the intended audience and research whether or not designing for 800 x 600 is really worth the burden. Most people nowadays have screen resolutions at or above 1024 x 768, so designing for smaller screens would make for an unpleasant experience for these individuals, unless you make multiple layouts, which then puts the burden on you, the developer. The individuals whose screen resolutions are lower than 1024 x 768 are most likely going to be older, or working from public institutions. Do they weigh heavily on your market? If so, then I would consider using a fluid layout and not fixed. That way, no matter the end users resolution, they can have a pleasant viewing experience.

    The author states that “a large chunk of the visitors to the site were using smaller browsers causing an image to partially block some ads.” In this situation, I would consider a redesign. You do not want to stymie your site by designing down as more and more people are going to continue to move away from 800 x 600. It would be more effective to either switch to a more dynamic layout, or reposition the ad space altogether.

    I also recommend taking a look at the 960 grid system (http://960.gs) as they have chosen a happy medium. This is to say that I recommend the technique and not necessarily the framework itself. I have learned from experience, that using a CSS framework can pigeonhole you.

    As far as the other points go, I can generally agree.

  • http://aenui.com/ AEN

    12 CSS files is not overkill when you are building applications with different CSS files for features, layout, type, colors, etc. The trick is to have these separate files joined and compressed into 1 file for the live site. I use cakePHP for that.

  • http://thoughtboxcreative.com Darren

    Although it is a good list, pretty standard stuff. would like to see a more advanced css mistake list, and I also disagree with css frameworks, if you know your stuff, writing from scratch is quick and easy.

  • http://elitenick.com Nick

    I’ve got a question: A lot of you guys are saying using “.floatleft {float: left;} is wrong, but what would I do when I have an image floating to the left on every post I make, and there’s 3 – 5 posts on one page. I want every main image in each post floating to the left?

    I’ve been using simply .floatleft but should I make it .floatleft-post-img? I feel like that method would make me end up having way to many extra classes down the road for other things I need floating left and right.

  • http://luispunchy.com David

    Adding my voice to the choir (Ryan, Ara, et al) on the CSS frameworks suggestion. Those frameworks mentioned in the article and their ilk (Blueprint, YUI, etc) are most certainly *not* the ideal for many (I’d say most) sites. I can see where they might work, such as for those working on tight deadlines and/or working in teams.

    But if you want optimized, semantic, and well-structured code that suits the specifics of your project (rather than the everything and the kitchen sink, bloated, overly generic approach of the big frameworks), you should definitely build your own framework and just reuse that. Of course as with all things in web design, use the tool that works best for your particular needs at the time.

    Everything else here = yeah, of course, those are definitely the basics you should be aware of when working with CSS. A good article for the would-be up-and-comers ;)

  • Drumsin

    I disagree with #4. You shouldn’t use such names as class=”right” etc. What if later in the future you decide on a redesign and your sidebar is on the left? It just adds an extra step where you’ll have to go through your markup rather than separate styles completely from presentation.

    It’s ugly in the HTML as well. This I feel is the equivalent of using inline styles.

  • Cheb Junior

    pretty simple, call the class .main so that you can access it like img.main

    each post should have a class on it also like .post… so to target the main image would be .post img.main

    code would be .post img.main{float:left}

    in future if the design changes and you want the image to go right, you just change the css, no need to change the actual html

    thats why you never use presentational mark up.

    here endeth the lesson

  • http://www.webdevelopment2.com/ Baz L

    Nice article, but your readers seem to be hating on it a lot.

    First off, let me say this: maybe as one of the top tutorial blogs out there, NETTUTS has a bit more responsibility than others. Kinda like the whole celebrity thing as it relates to free speech. So they should be telling people what is “right”.

    With that said, that’s why I tend to litter my own posts with “I/Me/I think/IMO/etc”.

    People, get over it. If you’re a purist; you shouldn’t need a tutorial. If you think this one is wrong, write your own. Say something constructive and move on.

    As far as all the talk against CSS frameworks. They have their place. Complex magazine-type layouts can be done in a fraction of the time. Are they overkill for a 3 column layout with a header and footer? Definitely. But don’t just rule things out.

    Now, on to the purists and their talk on semantics. I think this is a moot point seeing that different browsers don’t even know what the hell is going on. Who gives a rat’s behind about .fRight if it gets the job done? It’s not the Mona Lisa, it’s a stupid website. The point is to get something up and running. I can’t believe people sit here and bitch about semantics and in the same breath apply tons of IE hacks, that by definition should be no used. It’s a noble idea, but I think we should leave semantics (and other CSS preaching) to the next generation. Browsers right now, suck so much it’s hard enough to get stuff to look right. Why do they have default styles? Why is a browser reset even needed?

    I will, wholeheartedly disagree with #2 though. In this day and age, you can’t make such a generalization. It’s about your intended audience.

    And get off the dudes back about the .rightright thing. It’s a bug in the syntax highlighter. If you view plain text, it works out just fine.

  • Pingback: Help Developer - Graphic and Web Design Blog with Collections, Freebies, Tutorials and Forums » Blog Archive » A week in focus - November Week 2

  • Sean

    haha, I’m proud to say this.
    I’m 16, I’ve been doing XHTML/CSS for 2 years and I have not made any of these errors x3

    I reccomend reading the CSS mastery book, it is truly amazing, also a book I’m reading now, “designing with web standards, second edition” also a very good book :D

  • http://6v8.gamboni.org Mortimer

    There is load of good sense in this article, and I thought point 8 was going in a good way until I read:
    “why we use technologies like CSS is because it should speed up development time”

    The point of css is not to speed up development, it’s to separate content and style/layout… a side effect is that development is easier usually, but I think the main goal should be to ease the job of non graphical renderer (printer, screen reader, bots…), improving the accessibility of the website and its ability to be processed by machine (indexation, etc.).

  • Sean

    Also another for the list, having Classtitis, or Divitis (don’t really know the right spelling :p) that one can be a bad one too.

  • Beavis

    heh heh Fire! uhuhuh

  • Slinky Bill

    Mmmm that’s the government methodology in a nutshell.

    http://parks.tas.gov.au

  • http://madebyabe.com Abethebabe

    Those pictures make CSS seem much more intense! Great advice too!

  • Mel

    excellent point Mortimer

  • Pingback: Are You Making These 10 CSS Mistakes? - NETTUTS « llbbl

  • Pingback: Are You Making These 10 CSS Mistakes? | WhiteSandsDigital

  • http://www.geocities.com/jbarif B. Mohamed Arif

    Whatever it is highlighted is very basic, but very sensitive. The poeple who is going to learn and start to work with css, definitely need to read this article.

  • Fesh

    The only thing I like is CSS Frameworks is the reset. other class name is useless for me.

    only stupid will use 3,000px X 5,000px image size for a single colored background

  • James

    In regards to the point about inline CSS, having the CSS code implemented in your HTML page is not only bad practice for maintenance, it can also harm your SEO as the spiders would pickup the unnecessary coding.

    Overall, nice article.