Quick Tips to Fix a CSS Bug
I thought I'd share some of the ways I deal with bugs in my layout, leave some comments about your own ways if you feel others will benefit.
1. Check the layout in Mac IE5. I don't care what anyone says about Mac IE5 being an inferior browser, it keeps me honest. The Tasman rendering engine is still one of the best out there, and more often than not, if your design breaks in this browser then there's probably an inconsistency in your code as opposed to it just "not looking correct". Safari is very forgiving about overlapping padding/margin spaces so if it looks good in Safari but is bonked in IE5, then tweak the code until it looks good in IE5 and that will probably fix your bugs with both browsers.
2. Add some borders. The most common CSS bug in my work is when a floated element is too wide (or not wide enough) and some content gets pushed down because of it. Most likely the problem is with the 1) width of the element, or 2) padding/margins of the element. In order to exactly identify what part of the box-model is the culprit, slap some border: 1px solid red; on elements to find out precisely where its boundaries lie. A useful tip for doing unordered list navigation is to put a border around both the list item and the display: block'd link in order to determine why things aren't looking right. Usually a one-line padding rule can fix/break your work.
3. Write tight code. Are you using both padding and margin on an element? Is it really needed? If one of those isn't needed, then add the values together and stick them in one or the other. The reason for doing this is twofold: it makes for tidier CSS and it is now 50% easier to track a layout bug.
4. Kill those margins. As you know, most block-level HTML elements have a default padding and margin associated with them. When designing paragraph styles, one of my favorite things to do is to slap margin: 0; on the p style and just use padding to work it. Now I don't have to worry about margin-collapse and can have better control.
I've been writing CSS for awhile now, so as I start to code I already know where browser bugs usually show up. I try to keep my XHTML as semantic and tight as possible, and my layout as uncomplicated as possible. I've written before about using background images to make complicated layouts easier and I still feel it's good practice to get into. Why rely on browsers to make your overlapping, floated, bordered, round-cornered boxes pixel perfect if you could use a background image to accomplish the same effect?
Just some thoughts. What are yours?
I find that tip number 2. Add some borders is the best way to see how the elemets work, I also find that I always start with the border then taken the border off at a later stage.
Posted by: Matthew | Monday, February 07, 2005 at 08:22 AM
Excellent post Mike. A couple of things to add:
1. Use Tantek's undohtml.css -- strips default browser styling from (nearly) every element, so you can be sure that any styling is yours.
2. Use margin as much as possible. This is basically a technique that plays to Win/IE5's problems, so if that's not important to you -- then don't bother. But whenever possible, I try to think of things from the inside out, building layouts using margin only. Be careful of div/class/whatever-itis though. That's not much better than using nested tables.
(This is pretty much the opposite of your point #4, but it works well for me. I think heavy reliance on margin OR padding is manageable, but mixing them a lot is confusing. And you're asking for trouble.)
3. Check other browsers early and often. Following your point about Mac/IE5 (which is a good one), I try to check my layouts in FF and IE as early as possible, and then as often as possible. Safari is my browser of choice, but it's awfully forgiving when it comes to closing (or not) tags, which can be deceiving.
Posted by: John Zeratsky | Monday, February 07, 2005 at 09:27 AM
I zero padding and margins to start off with. Leveling the playing field a bit I think. If I start to get into trouble, differences between Firefox & IE I stick some borders on.
Knowing the most common bugs is extremely helpful so you don't get so frustrated too quickly. I tend to develop in a standards hugging browser like Firefox, then work around common IE browser problems.
Posted by: Trovster | Monday, February 07, 2005 at 09:37 AM
I definitely agree with the 0 margins note. For awhile I was into the habit of using negative margins on a lot of layouts (to account for browser bugs) but I realized that was just unncessary. As long as you have it set to 0 you can at least find out where you're starting from. If you know that, you can easily figure out where to go from there (most of the time...).
As far as dealing with background images, however, while it's good enough to use a background image to dictate the sort of "look & feel" of your website sometimes it can become unsemantic with the "nuts & bolts" of your CSS. I've gotten into the habit of doing webpages that have h1's with the background being the logo, etc., and using mostly open layouts. While backgrounds are nice for an overall page sometimes they can be overdone, I suppose, is what I'm trying to say.
Otherwise, thanks for the tips - and pretty blog, I should add!
Boy do I need to get moving and get mine up!
Posted by: Meredith | Monday, February 07, 2005 at 02:22 PM
Adding borders is the key for me. ("Oh, so that's what a div looks like.") But someone has to mention Chris Pederick's Web Developer Extension for Mozilla and Firefox. It can add borders for you, and show you exactly what CSS is applied to each element. I can't imagine working without it.
Posted by: Feaverish | Monday, February 07, 2005 at 04:16 PM
Steer clear of side padding. Always works for me. Nest a couple of divs if you have to. And remember about floating margins being doubled in IE. So I guess your point three is most important to me.
I keep IE5/Win open whenever I'm coding. I find if it works in IE5/Win and firefox, I rarely have trouble elsewhere.
Posted by: Pierce | Monday, February 07, 2005 at 07:50 PM
Three great tips that come from 3 gread coders:*
1) Add * { padding:0px; margin:0px; } to the top of the stylesheet. Saves so many lines of code.
2) Use as little padding as possible. Always try and create the desired effect with margins where feasable.
3) Use absolute positioning and display:inline instead of floats (again, where feasable). This has saved me so many headaches.
* I forget who, of course...
Posted by: Matt Hampel | Monday, February 07, 2005 at 11:06 PM
Matt, I wish you hadn't said that. I'm pretty mesmerized by source-ordered float layouts, and that search engines like them. I get tired of making a "tall" margin-top on a p to clear the absolute navbar. Seems tacky.
It's good to hear that Mac IE5 is useful. I use it a lot in checking out designs, hoping that its foibles are somehow related to IE Win. I've never seen my pages in IE Win, so it's like working blind.
There are more visitors to my site using Firefox than Safari or Mozilla. I love Firefox! It's great for outlining things and draws the page smoothly online. And the fox logo is charming.
I'm using the Phark img replacement on all pages. Hope I'm doing it right. I read somewhere that T. Celik said it's his favorite method. That's reassuring to me that it works in IE.
Posted by: Carole Danforth | Tuesday, February 08, 2005 at 12:35 AM
use *{padding:0;margin:0} in your css to gain complete control.
Posted by: mark rush | Tuesday, February 08, 2005 at 04:21 AM
I find it easier to develop using a reliable browser (Opera or Firefox). When you are completely happy with the layout, fire it up in IE. If it looks wrong, then you most likely have a bug (or two!) on your hands and you can employ the relevant fix.
I think it is also important to reset the default margin/padding values that come attached to headers (h1 -> h6), paragraphs (p) etc. I tend not to use the * { margin: 0; padding: 0; } line, as I feel it takes a bit of control away from me (especially where forms are concerned).
I also find it easier to add background colors to elements rather than a border, as the border obviously effects the width of the element. My favourite testing colors are:
#fc0, #f90, #369
Nick.
Posted by: Nick Rigby | Tuesday, February 08, 2005 at 04:23 AM
It would be difficult to zero-in on only one method I use to debug my CSS. I would have to say that the most popular of my methods would have to be going to one of your sites and literally stealing the code from your CSS files.
What, did I just say that out loud? DAMN IT!
Posted by: Colin D. Devroe | Tuesday, February 08, 2005 at 09:11 AM
good suggestions. ie5 for mac, mm? tough to start up.. ;)
also, i suggest you don't use borders when checking but instead apply background colours to all of your objects (a different one for each). that way, the border won't "bump" your perfectly-aligned design. just an idea that i got from garrett at maniacalrage.net
Posted by: mathew | Tuesday, February 08, 2005 at 12:10 PM
Get pissed and smash your computer!! Naaaw...I usually use borders. More than likely it's a box model problem.
Posted by: ryan | Tuesday, February 08, 2005 at 02:37 PM
Pierce:
Regarding doubled float margins. For the floating element apply the following.
display:inline;
Fixes it right up.
Posted by: Nico | Tuesday, February 08, 2005 at 07:35 PM
Hmm nice points......I don't use IE at all (Mac OSX) only for testing, I just launched it and its set to the default home page msn.com, and wow!!! It looks a little crazy....LOL.
Posted by: Shaun O'Connor | Tuesday, February 08, 2005 at 08:48 PM
Re: Web Developer Toolbar for Firefox:
Yes, it does make it easy to outline block level elements, but it seems to add either some margin or padding to the elements, throwing them out of whatever alignment you had them in. If your layout isn't very tight and concise, this wouldn't make a difference, but if it's built pixel by pixel, this could be a problem.
I suppose you could put a line at the end of your css sheet adding a 1px border to all block level elements you use. Hmm. I've never thought of doing that before. Would save time scrolling through css files.
Posted by: michael | Monday, February 14, 2005 at 07:58 AM
Thanks guys for all the tips. I've recently moved to floating divs (because of engines) as a way of building my sites, and I agree (whoever said it) that if you can get it to work in IE5 on Mac, it'll work on anything. And it's usually to do with getting:
- the exact size right
- making sure (on the mac) that you specify the clear option since I find that Mac for some reason, passes on the 'clear' setting onto child divs...
just my .2c :-)
Posted by: saul | Thursday, February 17, 2005 at 08:35 PM
Try expanding the * {padding:0;margin:0;} to this:
* {padding:0;margin:0;}
h1, h2, h3, h4, h5, h6, p, pre, blockquote, label, ul, ol, dl, fieldset, address { margin:1em 5%; }
li, dd { margin-left:5%; }
fieldset { padding: .5em; }
to fairly consistently rest the default whitespace. % for horizontal dimensions (relative to the browser window) and em for vertical (relative to font size).
See Gloabl Whitespace Reset for details.
Posted by: HeadJog | Wednesday, November 02, 2005 at 08:54 AM
Anyone ever have this bug with Firefox and CSS? - I have a specific site where an entire table is centered and then shifts a few pixels only on pages that go below the fold. It works fine in IE and if i make sure the pages don't go below the fold, it works fine. I'm wracking my brain on this one.
Posted by: Tom Markiewicz | Monday, November 21, 2005 at 05:45 PM
Well, on Mac OS IE doesn't work that bad - better than Firefox? I have modified my CSS recently and Firefox is the only browser I use (Opera, IE, Camino, Firefox) that doesn't display my colors. Or maybe Firefox is better _because_ of it?…
Posted by: Jean-Jacques | Friday, December 30, 2005 at 11:20 AM
Background colours work better than adding borders - with borders you're adding an extra pixel each side of the div which can cause problems/break the design
Posted by: sm | Friday, February 10, 2006 at 04:52 AM
For the shifting problem with stuff going below the fold, could it be that the introduction of a scroll bar to the right is causing the shift? It's irritating, but seems correct.
Posted by: colin | Monday, February 27, 2006 at 05:33 PM