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.
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.
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?
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}
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.
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:
- It means using unnecessary bandwidth
- 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.
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.
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.
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!
- 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!
Enjoyed this Post?
Subscribe to our RSS Feed, Follow us on Twitter or simply recommend us to friends and colleagues!
By Glen Stansberry
Join our newsletter!
Create a Tutorial, Get Paid!
Have something to teach the world? Want to earn money doing it? Tutorials, screencasts, and articles published here on Nettuts+ are largely contributed by readers just like you! We'll pay you great money for good content. Find Out More
I’m a big fan of 99% of the articles on this sit but this one seems extremely lacking. All of these points are highly debatable and calling the article “Are You Making These 10 Mistakes” makes it sound like the 10 commandments and we should all be ashamed for performing them.
For starters, try not accusing your audience with “you’re doing these X things wrong, you should be doing them my way.” Maybe a “these are tips and tricks that help me” or “helpful hints”. These are all items that, in certain scenarios can be great, but more often than not just add needless complication and headaches for no reward (validation, CSS frameworks). Don’t take my word for it, there’s some small time web designer NETTUTS interviewed a few weeks ago who calls CSS frameworks garbage too…crap…what was his name….oh right, Jeffrey Zeldman.
Also, LOL at the “don’t use mammoth images” followed by a completely unnecessary 600×900 picture. Priceless.
@Edward Boot, You’re argument for using tables instead of CSS has to be the worst ever – Who cares if it takes longer with CSS? – do it the right way or don’t bother at all! What you’ve accomplished on the server-side, no matter how many lines long has no bearing on what is right or wrong when it comes to front-end. I have no idea what you’re on about with the “bold” tags either. The ‘b’ and ‘strong’ tags are meant to portray semantic meaning, their appearance is totally moot – that should be dealt with in CSS.
@Baz L, So you’re saying “to hell with semantics and industry standards …as long as it works!”, how lazy are you!?
I find Glen’s articles always attract the most controversy… interesting…
Articles about coding practices always generate flamming and endless debates :)
I like to use YUI Reset/Fonts/Grid these days. Sure you can’t build all your site with it (deep nesting bugs for exemples) but I think it’s speed up the start and helps having a solid base whithout dealing with basic stuffs.
But for sure you can easily avoid it and do it from scratch.
It’s like the debate about naming class “left” “right” etc : xhtml/css being what it is at the moment it takes more time to not use it *a bit*, and you will not go to hell for that :)
“Why reinvent the wheel?”
– Because sometimes you end up with a round one…
css frameworks? sounds pervy!
Edward Boot:
I have no idea what point you’re making about bold text, but the author never said to use tables for presentation when CSS becomes a “hassle” but to use tables when they are called for — tabular data. Too many people frightened off by the mere word “table” will attempt to use CSS for everything, even when it is not the right tool for the job.
If it took you too long to make a simple website using CSS, maybe you don’t understand the language so well, and would benefit from a good beginners book? And I’m not saying that in a patronizing way.
I’m personally finding that a lot of the people in web design who blindly pride themselves on “learning it all on their own” would also benefit from a good beginners book that lays things out simply and clearly because they don’t grasp things as well as they think they do.
OH! And speaking of tables, all this talk about CSS tables is really exciting. Andy Clarke — who is amazing and needs to be read by everybody — briefly reviewed Rachel Andrew’s book ‘Everything You Know About CSS Is Wrong!’ which delves heavily into the topic.
Check out the post over at A Beautiful Web: http://forabeautifulweb.com/blog/about/are_css_tables_ready_for_prime_time/
Nice List. But I really don’t agree with point 8. Using a table to structure data other than tabular data is semantically incorrect. CSS is not made to make live easier (neither are tables) but to add style to HTML documents.
A very good related resource
CSS Implementations of the Rich and Famous: http://perishablepress.com/press/2008/10/26/css-implementations-of-the-rich-and-famous/
I agree with this list. I cant stand inline CSS it’s just wrong.
Great article. Excellent use of nontraditional images too.
i’m quite guilty in some points, but for the css framework i prefer to work from scratch i can better handle them
Am happy to report that I’m not making any of these mistakes! Phew.
Perfect tips ;)
Framework for a reset? Heres your reset:
* { margin: 0; padding: 0 }
Go from there..
@James. Funny thing is that you quote me, but I can’t find anywhere on the page (much less my comment) where I said those exact words. You need to learn to cite your sources better.
My point on semantics dealt specifically with fRight and fLeft. I think that too much emphasis is spent on semantics. When you multitask and jump for project to project, language to language, and everyone is expecting stuff yesterday, a fRight tag is gonna be the least of your worries dude. There are much bigger fish to fry.
Don’t get me wrong. I’m not advocating crappy code. However, as I point out, if the browsers can’t get it right, why are developers bending over backwards for semantics?
I agree with most of it, but I find CSS frameworks to be overrated. Might as well avoid it as much as possible. JS frameworks are highly recommended because of its ease of use and reliability. Then again, hand-coding from scratch takes you to the essence of the language, the raw material that is “programming”. Same for CSS, maybe even highly recommended. Its not about reinventing the wheel, but working around the wheel. How can you improve it, how to master your skill in that field.
This is actually my first time hearing about CSS frameworks, but the CSS Reset from YUI or other sites are the most helpful. Starting from zero let’s you code with less worry if they have different browser renderings. Of course browsers still read some HTML/CSS tags and properties very differently, but setting it to 0 makes it much better to design/redesign and manipulate them.
Just a reminder to those who haven’t use reset. My advise is to add it BEFORE you do any CSS work, or even before typing anything to the HTML.
For this article, I say learn from the comments here, many of them are correct. But try to learn more from others’ opinions.
For ease of trying to figure out, here’s a list:
Point 2 – get the required resolution first, because 800×600 is starting to disappear. Yes, it’s correct to test it on other resolutions, but what are the requirements. If its for web applications w/c will be used by private companies. They have a required set resolution size.
Point 3 – NO TO CSS FRAMEWORKS, well maybe a tad bit for practice use. But, anything within designing has always been done from ground up. Every painter or artist have tried to do their work from a blank canvas. CSS is very easy, my only recommendation, as the same with everybody, is using the RESET CSS framework, its a short CSS file w/c sets all the tags’ design to 0 (“a” will always have the underline, but who cares).
Point 4 – having classes that only changes a few properties are not recommended. When I’m designing, I have a template.css where I throw in my mostly used designs for that particular website/web application. I did that only once (mine was text12bBold, which holds a 12px #428bc9 Bold font, I had for green, gray, and other px sizes), was helpful somewhat. Except, when I started doing JS, i relied on getting the class to do unobtrusive scripts. Not very helpful if you have 5 classes in one tag. My recommendation is limiting the tag to 3 classes. This is my structure ( general class[when multiple tags have the same style, minimizes repeated CSS properties], specific class[specifies a design for that tag and so I don't touch the id], optional class [for JS-controlling styles or other uses, you can omit this]). By the way, DON’T USE THE PROPERTIES AS CLASSNAMES! You use comments to explain the CSS, not the class
Point 6 – it’s not mandatory, but recommended. Not all errors pinpoint the root cause. I’d rather make Point 5 mandatory, check all tags if they have their proper ending tags.
I asked my brother, who is my mentor, lots of questions when I was beginning web development. Most of the time he said, “Google it before asking me.” 95% of the time he was right. The remaining 5 were very specific questions. But the point here is: Google it first.
Point 7 – same as Point 2, but now, you enter to convince them why is it wrong to do BIG-ASS BGs. A repeating small image is highly recommended, but if required, you can’t do anything. But if you can convince them, they might reconsider. As long as you know what you are doing and what are you trying to say to them, they’ll rethink it. But there are some case that requires a big bg set to the top center and loading like two turtles having sex. Not very slow, but you’ll see it’s not very appealing to the eye. The two turtles are more interesting to watch than a huge Britney Spears wallpaper trying to load. You see what I’m trying to say?
Point 10 – Do you use “import url();” ? it’s like an external CSS, but being called by another external CSS. For example, you have a template.css and a reset.css. You want them to appear in your page with a page-specific css file you have. A good way is to call them all inside the page. But, if you can call just one but have all css files running, you can use “import url();” For me, lesser lines of code are better than a 1000-lined page. And you’ll have more space for comments if you’re doing a project with a team.
I also want to add one more thing: Please use comments.
Comments are under-rated by many beginners and some pros. Why comment your CSS? For retracing your steps and for the team to understand what the heck are you doing. Also used for debugging if ever comes to that. And, if you want to reuse that line of code, it’s easier to find the comment pertaining that certain CSS class property.
Also, if you’re a contractor/temporary worker, you can use them for your progress report. ctrl-c + ctrl-v = THE WORLD IS YOURS!.
I strongly disagree with #3. I don’t know of any company that would want their site to be design from a pre-made layout and design. That’s pretty tacky.
I still think we should let IE die or get better. We shouldn’t support it. Eventually, users will get tired of seeing tons of ugly sites and will use Firefox or Safari instead… but until we stop supporting it, we will continue to hack our CSS for a few more years.
great read!
Javier Centeno, it’s not about supporting IE, it’s about supporting the people who use it.
About the underscores, I have just one thing too say, Long live camel case.
@Sherlock As long as the classes name does what it says in a general way, then I think it’s semantic. For example, .unem mean unemphasize, which is general and semantic. It would be ‘bad’ if instead I had a .gray class and a .pixel12 class.
Anyway, using unsemantic HTML affects SEO as well as accessibility and potentially usability. Using class names like fLeft, unem, and clear do not which is why I think it’s okay to use them.
i would like to say great article Glen. i would, also, like to say that there are some people who have posted here who have said some pretty crappy stuff. pretty uncalled for if you ask me. i rarely post comments to articles and was inspired here.
keep up the good work Glen.
#7 Using Mammoth Background Images.
Images on this page are not mammoth but just too much :D
@Buzu: That’s what I’m saying, we need to persuade people to use better browsers. We would still be watching VHS videos if DVDs weren’t so much better. But because we continue to support IE, users don’t see the difference and continue to use it. Look at IE for the Mac, it pretty much died because of lack of support. Do users miss it?? It don’t think so.
LOL very good explanation and with burning image inside, really cool!!
I agree with most of the previous comments but I have to add one more mistake:
#11 – not using the Firebug ‘inspect’ feature.
haha, love the images in this post!
I agree, 1024 is very standard width for web layouts these days. Every major site now utilizes that width.
With this and browser compatibility is it also worth noting that designers need not always accommodate 100% of the population. Not only is that impossible, but it’s also a waste of time and supporting old technology only slows the development and full acceptance of the new, much better browsers…
Héhé love to see the web actors around take the user experience seriously. Keep it up guys !!
Very good article!
Javier, I completely agree with you, but there are better ways to do it. What you suggest is more like a good way to loose clients rather than to persuade people to change their preferred browser. BTW IE for mac died because the agreement between MS and Apple ended, but your point is that no one misses it, and you’re right.
like the article but not the image.
@James: Maybe he was talking about tabular data. So, instead of using CSS to display tabular data, use tables because that’s the purpose of it. Using tables for page layouts is indeed very nasty but not for displaying tabular data. Isn’t that right, Lubes?
Buzu, I know what I’m suggesting is a drastic change but think about it, if we as web designers/developers united on this, we would force IE to implement css better (and now!). Clients would not be affected, they would actually benefit from it. How?? Less time we spend fixing IE bugs = saving $$ for our clients.
We charge for our time, whether it is designing the front end, developing the back end, or hacking our CSS so IE can see it properly. We need to spend our time doing things that matter most such as usability and design. I think it’s absurd that IE forces thousands of developers to spend time working around IE bugs. It’s a waste of our time, which costs money to our clients. We need to stop doing that. But the fact is, we need to do it as a group, otherwise things won’t change for the good.
nice. I fond only Virtual PC can give a true indication of IE6. All these standalone browsers are no good.
Good info. .. Thanks!
No on frameworks – I’ve used them, and I’ve hated them. As it is, for most layouts I generally fly through the coding. After all – not every design needs to be intricate. Sometimes, a nice two-column layout with a header and a footer is all that a client needs – and wants. I’ve played with CSS frameworks, and frankly I find that I enjoy implementing it myself much better.
Another no on resolutions – while it is true that a header image should never be larger than 250 pixels to account for smaller resolutions, the general rule of thumb, as I have come to learn, is to design for 1024, as another commenter has pointed out. Of course mammoth resolutions should not be designed for, as office equipment rarely accommodate this and I doubt that users pay the fortune that we do for massive monitors, but I haven’t used a computer that utilized a 600 x 800 resolution since 1995 – over 10 years ago.
You do, however, get kudos for the points about validation. Even I have been “bad” with forgetting to validate my code. And as far as mammoth images go, it also depends on the image, the site, and the compression level of the image. I’ve seen some sites with large background images that load fine on a slower connection because the rest of the site was written in text. Now, if it is an image-heavy site with a large background image, I would have to protest against this sort of debauchery :)
asa kasindiran..heu..
It is an useful post for website developers. Hey, Glen. I am pretty impressed. You have done a wonderful job.
Hey Glen, you have incorporated great pictures in your post. This has really increased the visual appeal of this post. It is also a good one for website developers. I am sure, similarly like this work, you will rock us with your future projects. All the best.
Good info
Thanks
this is wonderful tutorial i will put acopy of this lesson on
my site here
http://www.as7ap4you.com
Honestly, I think these lists need to stop. Instead of just rehashing the same old CSS to-do or not-to-do lists, how about something a little more useful? Practical? Everyone does their CSS a little bit differently… who cares how they go about doing their styles and stuff as long as it gets the job done?
And to all of you who say that we should let IE die.. get over yourselves. Ooh, you’re some young hot-shot web developers, but you always run into problems with IE. Well guess what? Most people still use IE. Deal with it. I’m never going to force some grandmom to download some new program that does the same thing the old one does.
On the same note, people should stop flipping out about how people code their websites. I for one never learned tables, so I don’t really know what the deal is there. But if someone is comfortable making websites with tables, and can make them efficiently that way, who cares? When that same grandmom is visiting a website, she’s not going to look at the source and get pissed about the fact that the code ‘isn’t semantic’. Just make the website look good and usable. That’s all that matters.
Glen, Your selection of images is really excellent. Keep up the good work.
Good article, but I believe frameworks are useless. A thorough knowledge of CSS and browser compatibility will lead to better layouts and quicker rendering of code. Frameworks introduce extraneous elements (eg. many websites never utilize the h5 tag).
Hi, Glen. Your post is really an impressive one. The pictures you have used in this post are also great. Keep up the good work man. All the best.
nice pictures
Dear Glen,
Thank you for this nice list of images…
But I think there’s a bit too much text in between.
Here is another “do it my way css” article..
You know if you going to preach then validate this page.
Great article. It is only in the last point [using only one or two CSS files] that my opinion varies slightly. I typically have four CSS files: reset, layout, type, graphics. Each is separated for modularity.