No matter how much it may bother us, IE6 is still quite a hot topic around our little community. Two camps have recruited their groups and each seems quite comfortable with the accepted stance on their side of the fence. To one segment, IE6 is literally a bane of existence, and taking active aggressive measures against IE is daily practice. The other side, however, sucks it up and deals.
I often challenge my own stance on handling IE6, and have found what I consider to be a happy medium between both sides of this argument. I can’t in good faith stand behind the abrasive method of completely blocking (or severely limiting) access to a site based on user agent. Another way of handling things is to serve a completely alternate stylesheet, or remove the styles altogether. I prefer that solution over a roadblock.
At the other end of the spectrum, designers will do anything and everything to make the best of the situation, including tracking and billing time specifically for IE6 support. These designers seem to be most irritable when it comes to IE6, and understandably so. There’s a better solution. There is middle ground.
Support IE6, but don’t cater to it
I (and my company) support IE6. We do it because we have a strong feeling about accessibility, and supporting IE6 is really not a big deal.
The biggest calling to roadblock IE6 is by far its CSS “support” — that’s what gives the biggest headaches and leaves everyone running for the hills. The thing to remember, though, is that you’re a professional. With each project, working with IE6 is going to get easier. You’ll remember the disaster happened last time, and you’re going to remember how you fixed it. You’re not going to be faced with that problem this time around, or ever again. Get a couple years of that under your belt and you’re on Easy Street.
I’m not saying that your fixes need to go above and beyond a level of reason for the sake of IE6. The markup and style we’re writing is solid, right? There’s no reason we can’t quickly gracefully degrade a document either out of the box or by force. If that drop shadow is giving you trouble, tell IE6 it’s not there and continue with the next task. This design uses a series of PNGs to bring it to the next level? Don’t bother with PNG fixes; use a choppy GIF or nothing at all. Next.
My point is, that the frustration regarding IE6 comes from forgetting about the medium in which we work. Pixel perfection is a lost cause, and that not only deals with off-by-one-pixel situations, that expands to include the bigger picture including both design assets and behavior enhancements. Don’t try to replicate the beauty of the original design in IE6, just make it accessible and move on.
Aggressive Graceful Degradation
I’ve come to call this view of IE6 support Aggressive Graceful Degradation. Instead of relying on your implementation to fall back to a working version of something, you instead force the changes through gateways provided by IE6 itself.
My experience has taught me how to avoid any catastrophic issues as far as the box model (and therefore main document structure) is concerned, so the IE6 issues I deal with on every project are minimal at best. My IE6-specific stylesheets are mostly just a few declarations replacing PNGs with GIFs (or removing the image entirely) and
li fixes that I already expected to implement.
There are a number of other tips that I’ve come to learn in my career 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 tackling IE6.
The other main factor to which I can attribute the success of Aggressive Graceful Degradation is that I employ conditional comments to target each version of Internet Explorer in such a way that my fixes are implemented quickly and directly with no side effect other than a few extra bytes of bandwidth for standards-based browsers.
Conditional comments is a subject by itself, one that has been discussed up down left and right, and I’m hard pressed to find a negative stance that really takes hold with me. I’m more than thankful that Microsoft implemented conditional comments so long ago, as it is the single most important enabling feature of Aggressive Graceful Degradation.
Preparing your clients
Taking an Aggressive Graceful Degradation stance is the easy part, the hardest part by far is conveying both the cause and effect of this decision to your client and what it means for his project. To tackle this issue directly, my company has started including an additional document with our contracts, explicitly stating our stance when it comes to Internet Explorer.
We try to teach our clients as much as we can from the kickoff meeting through (and beyond) a site launch. More often than not, a client will appreciate the fact that you’ve taken the time to share your knowledge, and explain it in such a way that the information is useful.
This extra document is referenced in the contract copy and the client is required to sign, acknowledging that he knows his website may in fact render in a very different way, but retain full accessibility. I’d like to extend this document to the community, in hopes that it helps you to take a stance of Aggressive Graceful Degradation when it comes to IE6 as opposed to taking on an abrasive solution such as roadblocking the project.
If you’d like to find out more information regarding the Internet Explorer Contract Addendum please feel free to review and use the addendum in your own contracts, it is released under a Creative Commons Attribution-Share Alike 3.0 United States License. Suggested revisions are encouraged. A formal area for suggestions has not yet been established, but please feel free to contact me directly and we can all work together to make the addendum commonplace in project contracts.