Web design is about many things. I’d like to focus on a single aspect of Web design that is Internet Explorer 6. Not IE7 and its ability to put some makeup on what once was IE6, not IE8 and the great potential on that side of the fence. I’d like to focus solely on Internet Explorer 6, arguably one of the more popular (by usage statistics) browser for the next half decade.
Browser usage; who cares?
I follow usage statistics. I follow usage stats not only for my personal sites as well as prospective client sites (when possible), I also follow usage stats for existing client sites for which we collect analytics, as well as more broad metrics from services such as Market Share. As with all statistics, it is terribly important that you search for and validate as much data as possible before coming to any sort of conclusion. Browser usage metrics are values designed to be taken with a (decently sized) grain of salt. Of course user agent strings can be easily forged, and data sets can be easily skewed. The important thing to remember is: browser usage should still be of great importance to you as a modern Web designer.
I’d like to be completely clear in saying that usage stats should be important to you as a professional designer, but the numbers should not have adverse affect on your design. Modern Web design has taught us that a well balanced combination of progressive enhancement & graceful degradation can simply work wonders.
When it comes to tackling IE6, we can guarantee one another that there won’t be too much progressive enhancement going on. Instead, we’ll be putting graceful degradation at the forefront of our minds; thinking of straightforward ways in which to make the user experience equally valuable. My professional opinion is that IE6 should not be disregarded.
I do not propose that any exorbitant amount of time, effort, or money be put behind any sort of IE6 movement. I do feel that the choice to not support IE6 should be backed by useful data about your target audience, and at the very least a minimal version of your document be available for use.
IE6 and me
Every Web designer I’ve spoken with offers a familiar shudder at the mere mention of IE6, which usually turns into a moment of comradery between the two of us. It’s no secret that IE6 provides a sub-par browsing experience, that horse has been beaten to death too many times over (along with its entire family of IE6 horses) for my liking; and I’m not the only one. There are many designers who have taken the leap to complete lack of support. There are others who continue to describe each ache and pain provided by IE6 on a fairly consistent basis. Me, I’ve taken a more passive approach in accepting IE6 for what it is, and coming up with my own plan of action.
In my personal opinion, it’s going to take a worldwide colossal event to remove IE6 from our lives. Take for instance, the following graphs. These graphs represent browser usage on Monday By Noon, as well as usage statistics for a client website with a much more technologically diverse audience.
Monday By Noon is aimed at a very specific audience; Web designers and developers. To anyone who reads, questioning the market share IE6 possesses would seem to be a silly question. You would think it would be a safe assumption that IE6 market share for that traffic wouldn’t amount to much at all. I was surprised to find out that recent metrics show IE6 holding strong at 5% of my viewers. I cannot think of a decent explanation for that. Believe me, I’ve tried.
A more realistic (and therefore more useful) graph to take a look at is that of the general traffic website. Internet Explorer six is responsible for about 22% of traffic on that website. That percentage falls in line with what I’ve found to be (mostly) true with general traffic on the Web. At the time of this writing, about 25% of traffic on the Web is carried via Internet Explorer 6. To say that’s insignificant is simply untrue.
I feel that I should be completely explicit in saying that if your target audience simply does not coincide with numbers like these, and you’ve made the educated choice not to support IE6, I can find agreement in that. The important thing is that your decision was educated, not made by following the latest fad. Internet Explorer 6, in and of itself, still holds great importance to any Web designer.
That said, I’d like to share the details of my IE6 strategy.
Strategizing your IE6 process
Like all good outcomes, my accommodating IE6 starts by coming up with a plan. When reviewing design comps, I’ll start by visualizing the overall structure of the document and how the CSS will be applied to that. Before making the first cut, however, I will go over in my head what will likely give me trouble when working with IE6. Yes, IE6 has earned those five minutes of my time, and it will pay off ten times over when it comes to testing.
Throughout my analysis of the comp, I’ll decide whether various design features will be “worth it” to implement. The “worth it” scale considers both the target audience as well as the design purpose. If the target audience is minimal, and the design purpose is subtle, I will plan to gracefully degrade that feature. An IE6 user isn’t going to notice that there isn’t a drop shadow there.
I’ve honed my process so that the only hurdles left for IE6 usually have to deal with PNGs. Past experience will tell me whether a PNG will work within a particular application. If obtaining alpha transparency simply isn’t “worth it”, I’ll go ahead and use a gif. If the transparency offered by a gif will just look sloppy, I’ll figure out a way to use a jpg.
I’ve found that it isn’t worth my time to rip my hair out to make sure a design element is carbon copied from the design comp, if a gracefully degraded version will work out just fine. After all, we’re catering to a small(er) group of users employing a long expired browser.
Of course, tackling alpha transparency is hardly a well kept secret. By far the most frustrating thing to deal with when testing in IE6 is layout.
How to avoid layout headaches
Mastering the float is one of the biggest learning curve for modern Web designers. It’s very frustrating to finally grasp what’s going on only to realize the need to spend just as much time ‘making it work’ in IE6. I’ve seen it happen many times, and it will happen many more. Lucky for me, I’ve got two methods which have saved me many headaches when it comes to testing.
- Respect the Box Model
- As I’ve said before, something I always keep in mind is to avoid box model inconsistencies. Find a way to prevent setting a margin/padding along with a width/height. Stopping yourself there will work wonders.
- Margin and padding bugs with lists
- Even if you stop yourself from falling into Box Model traps, IE6 has a way of completely destroying your carefully styled list items. If it doesn’t have one, give the parent list element a width, and set
width:100%; float:left;to each child<li> - Control your clears
-
This tip heavily depends on your clearing method of choice. I’ll explicitly state that my experience has lead me to know and trust the
overflow:hidden;method of clearing. If you’re not familiar, addingoverflow:hidden;to a parent element containing floating children will force that parent element to encapsulate its children, effectively clearing itself. This method has worked well for me for years.Working with this method of clearing and IE6 requires you to have a small trick up your sleeve, though. Simply adding
overflow:hidden;to your parent element won’t work in IE6 if the element hasn’t triggeredhasLayout. Luckily this is (usually) a very easy fix. To force that parent element to clear itself in IE6, simply open your IE6-specific stylesheet and addheight:1%;.Adding
height:1%;will triggerhasLayoutand your element will now clear itself, allowing you to move on quickly. Of course this solution isn’t always perfect. This method requires you to plan ahead, setting up parents and children to cooperate. For me, this clearing method has allowed me to write lean, semantic markup, with a minimal IE6 contingency plan.It’s very important to keep in mind, however, that this clearing method can backfire and turn on itself. As your designs become increasingly involved, you’ll develop a tendency to toss
height:1%;on everything. Resist that urge. In order for this to work, you’ll need to only addheight:1%;on each of the parent-most elements you’re trying to clear. That’s not to say you can’t use this method more than once per design (you absolutely can). You just don’t want to end up overlapping your height declarations, possibly resulting in more hidden content than you started with.
Keeping those three tips in mind should give you quite an arsenal when it comes to IE6. Keep in mind that all you need to do is gracefully degrade. The more websites you design, the better you’ll become in dealing with IE6 during testing. Before you know it, your IE6 stylesheets will only be a few lines long, and you’ll be able to focus on the best parts of Web design, not the worst.
Do you have any IE6 rules you live by? What tips/tricks/techniques have you come up with throughout your career?
Comments
I totally agree with you (like always). In the agency where i work, we first check the (browser-) statistics , then we try to coordinate the grafic design and the programming. And in 99% the results of the statistics need to support IE6.
Sure the IT unit in firms have IE7 installed, but on the chiefs old laptop there is still IE6 installed (i don’t know why) and on the chiefs wife computer at home there is also IE6 installed. And she said to his husband: Why looks the brandnew site so ugly on her computer? She thought, that his husbands firm has the best web development agency in the universe….
That’s really true….
So we still develop for IE6 and i also try that the layout looks the same than in FF3, with all the transparencys, floats, Javascript functions, PNG’s, etc.
After 9(?) years of frontend development i know my “enemy” and it doesn’t take that long to fully support IE6. Like you said, there are always the same bugs to fix and if you set in a special IE stylesheet the elements height to 1% (the holy hack), you can fix about 80% of the layout issues.
But i yearn for the day where we can have a funeral IE6 party…
John, I agreed with you 100% right up until you mentioned the IE legacy stylesheet. I’ve found that in every single case, you can simply apply the height: 1%; hasLayout trigger directly to the style rule without any hacking or filtering being necessary.
For example, I tend to use a setup that puts the header first, followed by the menu, content, sidebar(s) and footer. These elements tend to be floated and cleared, while also using negative margins when appropriate. The content DIV also contains an internal wrapper that holds my page content.
That wrapper allows me to set up a float/negative margin setup that literally snaps the sidebar into place. Of course, the footer gets cleared by adding clear: left; to the #footer selector, but IE 6 and earlier need a hasLayout trigger to make it work properly. Adding height: 1%; directly to the #footer style rule allows me to do this without wasting any resources (including bandwidth and HTTP requests just for IE 6).
I have found that utilizing a CSS Reset goes a long way towards “normalizing” my layouts in IE6 (as well as other browsers). Another great method is to become familiar with relative/absolute positioning.
Using these two methods allows me to have one stylesheet instead of an additional IE-specific stylesheet, which saves a lot of time.
Well written article!
Just started reading MBN and am loving it.
As for this article, I’m with @Dan above. I do what he’s suggesting, and while one of my co-workers once brought up a valid fact: “adding the IE6 specific fixes in the original stylesheet adds bandwidth” I’ve never seen a few hasLayout fixes add even a kb to my files.
I think the Dan stopped just short of explaining the reasoning. For me (not sure why Dan does this but probably similar), its all about consistency. Tracking down an error in one place is golden for me. When I hit FF, I go to the one stylesheet. When I hit IE7, I go to one stylesheet, etc etc. I know that when I’m hammering down the dreaded IE6 bugs, I start with core layout technique for whats wrong, and move out toward specifics of hasLayouts. BUT! I ALWAYS know exactly where to look. And ultimately, when supporting IE6, its not that hard, given that your sticking to your guns with solid techniques, and investigating those first.
While not particularly hard to track down, Imagine the new front-end dev on your client’s team tracking down a bug, only to find theres ANOTHER stylesheet he wasn’t aware of. How frustrating (it’s happened to me countless times)! I doubt you do this, but imagine the willy nilly devs that drop in IE7 and IE6 sheets. They don’t show in Firebug, and IE’s tools are crap.
Imagine now, if everything were in one sheet. In no matter the browser, you can start with a stellar debugger like Firebug. From there, you can get a refresher on whats happening with the problem wrapper, and then get moving with some guess and check or cut straight to the problem.
Grocking a stylesheet is hard enough when your coming in after someone. Grocking 2, or 3, well, another story all together right?
Also, here’s a great alternative to height: 1% that you probably already know but I’ll say for posterity’s sake: zoom: 1.0. This works soooo well, and doesn’t mess with your heights.
The only thing that zoom: 1.0 doesn’t fix is absolute positioning paying attention to padding in 6. That is when I reign in and drop back to height: 1%. But height: 1% can get scary and can, like you mention above, blow out your height settings. Zoom: 1.0 is a much more friendly fix.
To conclude, I’d like to add one more thing to my book here: This is my basic IE6 “hasLayout” bug fixing process.
I’ve wrapped the CSS and browser checking for all but IE6. It looks stellar, but explodes in IE6. After awhile you get a spider-sense for the hasLayout bug, but sometimes, you just know its there, not what parent to apply it to.
I’ll go ahead and add * { zoom: 1.0; } to the css, just to see if it fixes. And from there, I’ll start adding it to wrappers. And then narrowing down the wrappers. And then stepping into each wrapper and into the elements, etc etc until I’ve come to the parent that fixes.
Lately now, I just know, but in the beginning, while grocking the overflow: hidden, I didn’t. The “* to direct parent” method is a good one for newbies to the process.
Good shiz Jon
Realized that the above needs a summary, woah that got long, lol.
1) 1 stylesheet is nicer, and the height: 1% and hasLayout fixes don’t add enough overhead to care about file size, but do add kindness to your down the road devs.
2) zoom: 1.0; is a great hasLayout fix for everything but absolute positioned items paying attention to padding (a common IE6 hasLayout bug). For the abs pos bug, height: 1% is necessary. Zoom: 1.0; works well because it won’t murder your height declarations.
3) A good and common method for being new with hasLayout bugs and where to put the fix is to start with * {zoom: 1.0}, and then work in from there, just to see if the hasLayout bug exists or not.
Brevity is king lol. Sorry for the book above 😉
Nice posting – I agree with targeting audiences. And @Matthew I agree that CSS Reset works wonders.
**but in the case of clients, optimizing for IE6 should be be an additional charge. Additional testing and optimizing for IE6 takes more time.
In general I don’t think it is fair to penalize users (who “don’t know any better”) – so yes, graceful degradation is ideally the best policy. In addition, as a form of activism I like to include a IE6 specific script: “You may want to Upgrade Your Browser!”
I recently wrote about the 25% IE6 phenomenon here:
http://mastersofmedia.hum.uva.nl/2008/12/01/why-is-the-university-of-amsterdam-still-using-ie6/
What a terrific response so far! Thanks everyone!
@Ole: Absolutely. Something we try to do at my company is educate clients from the first time we meet. We explain that we build websites based on the Web standards school of thought. We merge that into a discussion of browsers, reiterating that there are standards compliant browsers, and there aren’t. Before a website contract is signed, we try to make it explicit that an end product will more than likely include some differences when viewed in IE6, and we try to explain to the best of our ability why that is. More often than not, clients are very accepting to the fact that IE6 is a sub-standard (literally) browser, and accept the fact that the majority of their viewers will be presented with the version displayed in the approved comp.
@Dan Schulz: I’ve been a long time proponent of using conditional comments to pass off IE-specific style sheets. Using conditional comments puts the burden of the HTTP request on IE only, not well behaved, standards compliant browsers. To me, it’s the best of both worlds. My screen style sheet isn’t cluttered with extraneous properties and values (cleaner) and anything IE specific is kept in a separate document entirely. There’s definitely two camps when it comes to conditional comments, each with very strong arguments. Maintaining a separate style sheet has taken minimal effort for my company, so we continue to employ that method. Thank you for your contribution!
@Matthew Muro: Great point! I loves me some reset CSS. You’re absolutely right; a reset style sheet will indeed go a long way when it comes to handling cross-browser inconsistencies.
@Ken Hanson: Wow! I’m blown away by your response(s)! Thank you so much for taking the time. Terribly good point: working on a team always generates more difficulty when cross-browser testing. Lucky for me, my team is smaller, and we’ve all come to the same conclusions about organization methods. I’m very thankful that we all think alike in that regard. As I touched upon earlier, my team hasn’t had much trouble with maintenance, but I can absolutely sympathize with maintenance disasters occurring. I love your Spider Sense analogy with hasLayout; that is by far the most perfect way of describing it! Something I struggled with when writing the original article. I’m definitely going to keep that in mind from now on. Thanks very much for including the note about
zoom:1.0;. Now that I think about it, using that property is slightly more applicable in a semantic sense. I know that’s a stretch, but when triggering hasLayout,height:1%;does indeed work, but you’re not trying to set the height to 1%, you’re preying on a well implemented bug within IE6.zoom:1%;on the other hand makes a small bit more sense. When reinforcingzoomto trigger hasLayout, it appears more as a redundant property/value combination as opposed to something out of left field. I can imagine someone new to front end development asking himself “why would this guy be setting such a small height?” Thanks again, very much Ken, for your well prepared response, and I hope you continue to enjoy MBN!@Chris Castiglione: Absolutely, charging for additional IE testing would be ideal. The way we handle that at my company is simply including that time in the original project estimate, it’s included in the overall project price. We do not, however, provide an itemized list stating that “IE6 testing is going to cost $X.XX” as that would raise a number of eyebrows. As a designer, you should indeed be compensated for your work, but it will always be in your best interest to get to know IE6, and plan for her shortcomings, leaving minimal time spent catering to a lingering browser. Thanks for the link!
Again, everyone, thank you very much for taking the time to put together your responses. You’ve absolutely boosted the value of this article and I can’t thank you enough.
I have no problem using conditional comments when the situation warrants it (like when using properietary behaviors, expressions, filters, and properties), but when possible, I steer clear of them.
I’ve been beginning to look into JavaScript to enhance the accessibility of Web sites in IE 7 and earlier (such as IE 6 not supporting the ABBR element for instance), and in cases like that, a conditional comment is ESSENTIAL if you don’t want to trip other browsers up when using object or feature detection to sniff out those older browsers.
Of course there’s also the case of IE (up through version 7) not supporting :focus properly (did I say properly? I meant at all), so once again, conditional comments come to the rescue – especially since I won’t deploy a site with an invalid style sheet.
In fact… I might have to contact you privately (if you don’t mind). I have something (a new way to use conditional comments) you might want to take a look at before I make it available to the public. (Besides, having another set of eyes just might help make it that much better.)
If you’re interested, well… you already have my email address. 🙂
I like your take, Jonathan. Having the ability to quickly and easily adapt from one task to another is enhanced through proper training and expecting the worst. Prepare your code for those wild bugs by learning and improving over and over again.
It’s very hard for developers that have recently started to support IE6.
The problem is that, there are soooooo many hacks it’s ridiculous. For my personal development, I have decided to go with this:
http://code.google.com/p/ie7-js/
There are many people who will be against this because of it’s dependency on javascript.
I’ve never had a problem that it didn’t fix. I personally have a problem with dumping styles (many of which I don’t understand) just to appease IE6.
Just my two cents.
@Dan Schulz: What’s great is that many JavaScript libraries are now using feature detection in opposition to browser sniffing to make sure your code isn’t executed when you don’t want it to be. I’m definitely interested in checking out your new approach to conditional comments, keep an eye out for my email.
@Mark Otto: Without a doubt. The more websites you build the more you train your ability to catch yourself knowing that something isn’t going to work out in IE6. When you’ve reached that stage, you’re in a great place.
@Kevin Lloyd: IE7 JS is a terrific tool. Of course there will be nay-sayers against the technique, but it absolutely solves many of the problems you’ll face when supporting IE6. Thanks for the link!
[…] Fear not. I Have Conquered IE6, and You Can Too […]
It is a well written article with valid points but I guess I’m a Dick because I say IE6 go away. It is bug ridden, non standard, and takes longer to develop quality web sites. I don’t think it would be such a hardship for people to go to web sites that work on every browser but IE6. They may have to download a new browser. Perhaps you should read the opposing article located here
http://creativebits.org/webdev/finally_microsoft_putting_ie6_death
Please do not take this the wrong way, I just have a different oppinion.
[…] that make IE6 less than a bleep on the radar on any project. I documented a number of these tips in Fear not. I have Conquered IE6, and You Can Too, hopefully there are some things that will help you out if you’re having a bit of trouble […]