Fix It Fast: Rapid IE6 CSS Debugging
IE6: We all hate it, and we all have to work with it (well, most of us). The most frustrating phase of buildout is often the final struggle with this Browser From Hell, but maybe (just maybe) we're struggling too much. When I help friends with IE6 bugs, I'm sometimes surprised at how long they've been stuck on a single problem, or how they've painted themselves into a corner with hacks and fixes. Then I remember that I used to be like that, grinding away for hours at simple float issues, or pulling my hair out over list spacing.
Why do we have so much trouble learning to debug for IE6?
We don't know! There are a lot of bugs out there, and it takes a while before you can intuitively spot them. If we can't identify a behavior, it's easy to throw up our hands and say "Augh, it's just BROKEN!"
We don't want help! Many a designer has spent hours on a problem simply because they didn't ask for help or Google it. With a language as straightforward as CSS, you can eventually solve most problems just by blindly changing stuff (over and over), but changing stuff doesn't mean you're learning.
We're not sure how to start! Debugging is a weird process: At any point, you could come across THE SOLUTION, which would be GREAT, and it always seems like it's JUST AROUND THE CORNER. This constant bait-and-switch means that we don't settle into a solid process for debugging, which, in the end, means debugging can take much longer than it should.
So, is there a way to shortcut through some of the hair-pulling and learn good debugging right from the start? MAYBE. The following is my cycle of preventing, catching, and fixing bugs in IE6. If I could, I would email it to myself in 2004, but until I figure out how to do that, posting it here will have to do:
Preventing Bugs
You can avoid a lot of IE6 bugs right out of the gate, by writing around some of the common stuff.
Planning the structure:
- Avoid tight fits of floated elements. If you have four floats squeezed into an area, consider removing the pad/margins on the last and floating it right instead. Tight fits can lead to the "repeating content" bug in IE6.
- Plan to put either a width or a padding on an element, but not both. Instead, place padded elements inside a fixed-width element. This way, you don't have to wrangle with IE6's box model issues.
- Be aware of vertically short (~15px or less) elements, which might require some hacks later on.
- Be aware of sized floats appearing in content areas, which might trigger float model.
- Think about content that might expand past your box size. This might trip up IE, as it tries to expand the element to fit larger content.
Writing the markup:
- Keep floated elements from being adjacent to absolutely-positioned elements, and thus avoiding the "peekaboo" bug.
- Be careful to close every tag. Firefox sometimes closes tags for you while rendering, but IE6 will be less forgiving.
Writing the CSS:
- Start off with a reset to clear out unwanted browser defaults.
- Avoid #id.classname selectors...these have a tendency to break in IE6.
- Avoid left and right margins on floats...this means fewer fixes to make later.
- Be aware of using bottom: and right: when absolutely positioning. These might require some special IE6 attention later.
Defining Bugs
The key to quickly fixing bugs is to acquire a subtler understanding of what's actually happening when rendering goes wrong. There are a lot of questions to answer about the element that will give us a clearer picture of what's happening:
- Is it the wrong size?
- Has it expanded?
- Has it disappeared?
- Or, has it simply moved?
- Is it being covered by another element?
- Is it not stretching properly?
- Is the background disappearing?
- Is it happening in IE7 as well?
Sometimes you can't easily pick out what's happening, so it helps to add some borders:
div { border: 1px solid red !important; }(Note: If this happens to magically FIX your problem, try using position:relative or zoom:1 on the element)
Once you've isolated the bug down to one or two elements, glance over the CSS and see if there are any unique or particularly troublesome properties on the element. This'll help you with the investigation. Once you have the browser, the effect, the element, and the css property in hand, it's time to investigate.
Investigate Bugs
Now that you know what your bug is, let's see what someone else thinks about it. PositionIsEverything has a good list of common bugs, but I usually go straight to Google.
A few recent, fruitful searches:
li ol number 1 ie7
float negative margins ie6 doubling
id class ie6 bug
ie7 not showing images
As I said in the last step, the clearer you are about what your bug is doing, the easier it is to narrow it to a single browser, element, or CSS property. 90% of the bugs you run into will be from the same small group of common issues, so searching with the right terms should turn up some good answers.
Fixing Bugs
Many rendering bugs are fixed with a few common techniques:
- Properly clearing floats (with a clearing div or clearfix)
- Trimming the left/right margin on a flow in half (to compensate for IE6 margin doubling)
- Using word-wrap: break-word or overflow:hidden (to combat expanding boxes)
- Applying position:relative to the element or its parent, or
- Applying the "zoom: 1" property to the element
You should be able to find more specific issues, or true oddities, out there on the web somewhere.
Note that all fixes should be done in special stylesheets linked using conditional comments. This way, your fixes stay separate from the main stylesheet, easy to find and work with later (and, it keeps your main stylesheet valid). Writing comments about fixes (especially weird ones) is a great idea too, and it keeps the next designer on the project from needing to go through the same process.
The next time you're stuck on an IE6 bug, give this process a try - define, investigate, fix, and then think about how to avoid next time. If you're still having problems (it's pretty likely), keep at it, or leave a comment about what I missed.
Some Reference:
You can solve both the doubling of margins and the duplicate characters bug by using display: inline;
That’s true, but usually these issues appear on items that you need to display as block-level elements (columns, etc.)
I agree with you when it comes to highlighting troublesome elements. I like to give elements a background-color if they have a width set, or border-color for other elements. I, like you, also like to use CSS color names such as red, yellow, blue just because it’s easier to type and stands out more.
The trouble with many browser bugs is it’s difficult to put into words what is happening when you search Google and get meaningful results back.
I almost forgot, my favorite thing to do with IE6 is use the underscore hack in my main stylesheet while testing ( _width: 65px; ) and then once I’ve determined the problem, move that property to my IF IE 6 stylesheet w/o the underscore.
What about using the ie6.js and ie7.js javascript files by loading them via conditionals to?
What’s your stand on using those javascript files? Do you guys use it?
Waaah, After reading your post’s title I thought you were going to introduce a version of Firebug for IE6 ;)
@peter: http://getfirebug.com/lite.html
You can use firebug in other browsers. A neutered version of firebug, but still firebug.
Great article by the way. Just a quick note on the CSS reset. if you do want to reset:
1) Don’t use * { rule:properties } use a proper reset.
2) Put some defaults back in. HTML tags are useful BECAUSE of thier inherant properties, I prefer to not have to apply styles to HTML tags where the design allows it.
Personaly, I use an adapted version of the blueprint CSS framework reset.css (which I think was originally based on eric myers reset), typography.css and forms.css.
“Avoid #id.classname selectors...these have a tendency to break in IE6.”
You should rephrase that. A single class name on an ID, like in the example, works just fine. It’s when you add additional classes beyond the first, then only the last class name is recognized. e.g.
#id.class1.class2
Everything in .class1 is ignored, but .class2 works
We should let it die already. 3 ways to do that:
IE6 Update: http://ie6update.com/
ie6-upgrade-warning: http://code.google.com/p/ie6-upgrade-warning/
sevenup: http://code.google.com/p/sevenup/
@Neal G - Background colors are a nice indicator too, especially when you’re targeting an individual element with them. The underscore method looks pretty nice...I tend to just make the changes in the IE6 stylesheet, but sometimes this gets confusing if the stylesheet’s not loading properly ("Why is this still broken??")
@Terjin - You’re referring to files like this, right? I’ve stayed clear of these due to the filesize and a paranoia about javascript interactions, but I should probably investigate more. IE7 bugs are generally rarer and easier to fix, so a full JS file that mass-eliminates bugs seems a bit like overkill.
@peter & @rich97 - I tend to just go back into Firefox and point at the item in question for more clues, but Firebug Lite looks awesome.
Re:reset - Point well taken. My reset starts with a * {margin/padding:0} and then goes into a section from Blueprint’s reset, coming out with a few helpful defaults (p spacing, abbr underlines, etc) and a form framework (courtesy of Jackson Wilkinson). Rebuilding all those styles from scratch every time would be a huge, unnecessary time-suck
@Brian - I’m actually referring to this bug, which can be a huge pain when it appears. IE6 has difficulty dealing with similar #id.class selectors like #content.highlighted and #content.not-highlighted...it ignores the rules of the second one.
@Buguletzu - Even Facebook is doing this now, so I’m slowly leaning towards adding it to my own stuff. But it’s not a magic bullet: some users ignore it, some think it looks like a scam/virus, and some don’t really know what it means (or they have difficulty upgrading, due to Microsoft’s frustrating upgrade system).
The truth is: If you’re doing serious web work for a client whose users are 10% IE6, you need to create a working (if not perfect) experience for them. That’s 10% of their web business. Encouraging the users to upgrade might be acceptable, but breaking their experience really isn’t.
As computers die and get replaced, we’ll see IE6 slowly fade away, but the debug process mentioned in this post will continue to apply (somewhat) to other issues. Learning to debug CSS methodically is a valuable skill that you may as well use IE6 to practice on!
We have a lot of our IE6-debugging time down to a minimum now. especially thanks to the conditional comments you mentioned. Folks, if you’re not using these you’re making your life much more difficult than necessary and making your CSS code more unreadable with “hacks.”
Let me suggest another strategy for IE6 though: if you can’t get it to work, and it’s a nice display flourish, use the IE6 conditional stylesheet to offer a pleasant, but degraded, experience. By current standards IE6 is a primitive browser; a degraded presentation is perfectly appropriate. This, too, is responsible for cutting a lot of our IE6 debugging time.
@John - That’s an excellent point. I’ve started using PNG-24s for a lot of effects, but rather than spending the time/energy to keep the IE6 hacks for these working, I just make mediocre-looking IE6 versions. It’s often good to ask yourself “do I need to FIX this, or can I just degrade it?”
Another method for dealing with PNGs in IE6 is DD_belatedPNG, it allows for positioning, repeating and so forth.
My take is that we’re giving visitors too much power and control over the web. If only 10% of developers tell their visitors to upgrade, then we’re basically shooting ourselves in the foot, accepting that this is ok as a whole. The IE6 user comes to the site, says to himself that it’s the site that it’s broken and leaves. But what if 90% of developers dumped IE 6 altogether? Then we’re not the weirdos anymore, they are, and they will be forced to upgrade.
@Buguletzu:
I completely agree. I was recently in an interview where they brought up my site in IE6 and I was embarrassed at how it looked. I apologized and said I’d get right to fixing it. Since then, however, I’ve decided to simply state that my site is not optimized for IE6. I’m more than sick of making up for Microsoft falling short.
I think it is about time that people should no longer be using IE6. As a designer it just makes your life a lot harder to do just the simple thinks and you can spend hours trying to figure out a straight forward problem.
My final position on this:
a) Many people are still using IE6.
b) These people are the potential customers, patrons, community-members of our clients.
c) Breaking their experience will not “force” them to upgrade, it will simply “force” them to choose other websites and retailers.
We’re talking about 10-20% of the business some websites get. Given the choice of ditching IE6 or seeing a 10-20% jump in web business, I think most clients (and hopefully, designers) would choose the latter.
“Sometimes you can’t easily pick out what’s happening, so it helps to add some borders:
div { border: 1px solid red !important; }”
Using this CSS has helped me learn and solve more than a few bugs. A co-worker showed me that trick and I’m glad to see someone else suggest it for bug fixing.
There are several bookmarklets out there that will do things similar to firebug or the web developer firefox extensions do. Changing the background colors and adding a colored border to see what is going on, helps a lot also.
Thank you for good advices and discussion.
And - I wote for Firebug for IE!
Next entry: Making Quicker Interface Decisions With Design Patterns
Previous entry: Design Share 2: More With Less
Recent Comments
@brad
It makes little difference when using native EE functionality or Structure to add pages, it’s just that if you want to add a sub page, you need to remember to assign a...
- Hambo on 'A Whole New Wooooorld: Structure + ExpressionEngine'.
- brad on 'A Whole New Wooooorld: Structure + ExpressionEngine'.
- Doug Avery on 'A Whole New Wooooorld: Structure + ExpressionEngine'.
Subscribe to Comments RSS