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.

Another major reason for roadblocking IE6 is JavaScript support. Even though we’re working with superb JavaScript libraries, things sometimes just don’t work out the way we expect. Here’s the answer for that:

JavaScript enhances the document viewing experience by adding an additional behavioral level, right? We’re talented professionals who have already built a fallback version of this document to directly compensate for the absence of JavaScript, right? Our problem is solved: IE6? Don’t fire our JavaScript. If it’s going to be a headache, why bother? We have a perfectly good version of the document that was only progressively enhanced by the JavaScript. IE6 can’t hack it, so just shut it off. Deliver the reduced experience because your viewer, for one reason or another (it doesn’t really matter, does it?) is using a terrible browser.

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.

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, adding overflow: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 triggered hasLayout. 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 add height:1%;.

Adding height:1%; will trigger hasLayout and 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 add height: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?

Additional Reading

• Stop being a dick, support IE6

Last week, a project was to enhance a form on a client website by integrating the addition of new fields via JavaScript. The basic idea is this; there is a section in the form where a number of file inputs would need to be duplicated based on the need of the reader filling out the form. The number of file inputs could range from one to an unlimited number, which, come to think of it, I need to revisit. But I digress.

As I was working with the form, I began to notice that it wasn’t working improperly in Internet Explorer 6 or Internet Explorer 7. The script kept track of how many inputs had been added via a simple counter, and provided a name attribute reflecting that number using an established naming convention. It was the basis for allowing multiple file uploads.

I tested again using Firefox and everything appeared to be fine. My next step was to check out what was going on with the DOM in IE.

Viewing Generated Source in IE

As we all know, there aren’t too many developer resources for working with Internet Explorer. The Internet Explorer Developer Toolbar is about the only tool that really helps you to diagnose any troubles you may be having. It has come in handy for me from time to time, but personally I think it’s a bit awkward to use and generally end up resorting to a quick border:1px solid #f00; to help me diagnose any troubles I may be having with CSS in IE.

In this case nothing like that could have helped, so I resorted to the Developer Toolbar and realized that none of the created elements had a name in Internet Explorer 6 or 7. Everything was working fine in other browsers, so I wasn’t sure exactly what was going on. After a bit of searching, I found that IE simply does not support the application of a name attribute to an element created via DOM scripting. Ridiculous.

As an aside, I also came across a quick tip on replicating the View Generated Source functionality of the Web Developer Toolbar for Firefox, a feature I find myself using quite a bit. You can explore the generated DOM using the Developer Toolbar in Internet Explorer, but the following snippet will display the generated source in plain text, just paste it in the location bar.

javascript:'<xmp>' + window.document.body.outerHTML+ '</xmp>'

Continuing: A bit more research narrowed the scope of this ‘issue’. It turns out the IE more specifically does not allow the name of an element to be changed after it has been created. Bummer. What do do about it?

Thankfully, the Internet is full of extremely intelligent people. Most of the time, other people have had the same exact problem you’re having, they have written about it, and also (hopefully) provided a solution to help you out. This was one of those cases. In the article Setting the “name” attribute in Internet Explorer, a fix for this problem is offered in the following function:

function createNamedElement(type, name) {
  var element = null;
  // Try the IE way; this fails on standards-compliant browsers
  try {
    element = document.createElement('<'+type+' name="'+name+'">');
  } catch (e) {
  }
  if (!element || element.nodeName != type.toUpperCase()) {
    // Non-IE browser; use canonical method to create named element
    element = document.createElement(type);
    element.name = name;
  }
  return element;
}

Essentially, the function checks to see whether or not the reader is using Internet Explorer, and implements the element accordingly. I also happened to find another solution that uses the conditional comment method:

/*@cc_on @if (@_jscript)
var newNode = document.createElement('<input name="'+elementName+'">');
@else */
var newNode = document.createElement('input');
newNode.name = elementName;
/* @end @*/

Many developers have their own opinions about using conditional comments both in (X)HTML as well as JavaScript, so it was nice to find examples both with and without. Which would you prefer?

Hopefully, if you haven’t come across or read about this bug before, you’ll remember it when it comes to your next Web app as you ad progressive enhancement in dynamic addition of elements requiring a name.

References

• View HTML Source Generated by AJAX
• Setting the “name” attribute in Internet Explorer

When I use conditional comments

Up until this point, conditional comments have saved the day for me simply by being present in the head of my documents. For nearly every client project, I find myself using conditional comments to target both Internet Explorer 6 as well as Internet Explorer 7. In my opinion, as far as standards compliance is concerned, IE7 is merely a shuffle forward, as opposed to a step.

I’ve also accepted using conditional comments to include JavaScript written specifically to assist Internet Explorer. A specific example that comes to mind is when I’m implementing Suckerfish Dropdowns. I elect to include the JavaScript with a conditional comment simply because the script is only meant to be run when browsing the document in Internet Explorer 6. I prefer to have other browsers ignore the JavaScript for simplicity’s sake. While it may not be considered harmful to allow JavaScript such as the bit needed for Suckerfish Dropdowns in all browsers, to me it is settling to keep it separated.

Using conditional comments in the body

Until recently, it hadn’t even occurred to me that using conditional comments in the body of your document could become commonplace. There’s no documentation specifying that conditional comments can be used only in the head of your document, so why stop there? To me, using conditional comments in the body of your document is partially counter productive.

The reason I choose to employ conditional comments is their nature of providing longevity. By writing specific style sheets to target specific versions of Internet Explorer, I’m able to solve a rendering issue and leave the solution as is for the life of the document. The problem is solved with a minimal change to the DOM.

When you choose to use conditional comments in the body of your document, you’re electing to alter the DOM in a more significant way. Now, instead of working with different style sheets to solve a problem, you’re altering the problem itself. If this route is chosen, you now have a number of choices. You can alter a significant portion of the DOM in order to work with a single, existing style sheet, or you can take both sides and use conditional comments to include Internet Explorer specific style sheets as well as alter the DOM at the same time.

The idea in general, to me, seems more sloppy than resorting to the use of CSS hacks strewn throughout your document style sheet. Your source will become ugly and awkward to maintain, and the longevity of your document will be greatly reduced. Using conditional comments to include a version specific style sheet (or a bit of JavaScript) should be all the ammo you need to solve the problem of Internet Explorer.

What’s your opinion?

How do you feel about conditional comments in the first place? If you’re opposed, is it due to the fact that the code is technically proprietary? Is it due to the fact that the implementations you’ve seen are as outlined above in that conditional comments are littered across the entire DOM?

Safari Available for Windows

I’ve read a number of articles that were written as a direct response to this event, a post by Mr. Hicks as well as a reaction from Mr. Snook, among others. While Mr. Hicks offers some intriguing questions, I found myself agreeing with much of what Mr. Snook had to say regarding this release.

He said that the release for Windows really doesn’t do all that much for developers working in Windows, with which I agree 100%. Safari uses WebKit, and Safari 2 uses a completely different WebKit than Safari 3, so a Windows developer getting their hands on Safari 3 isn’t doing anyone much good. The improvements implemented in WebKit are exponential in it’s current form when compared to the version used in Safari 2. If you’re looking to test using various operating system and Web browser combinations, it’s best to use them natively (or at least in a virtual machine) in my opinion.

It can’t be ignored what a big change it will be for Windows developers to be able to test in Safari, but in my opinion, this situation (when Safari 3 comes out of beta) will be very similar to the IE6/IE7 mixed distribution. While it will be nice for Windows developers to be able to test in one browser, it will still require a run-through in Safari 2 as well. As will happen with IE6, Safari 2 will eventually be overrun by Safari 3, but that will take quite a bit of time.

Will anyone really care about the release?

So if the release doesn’t help Web developers, will it have any sort of effect on the general population? In my personal opinion, Safari wasn’t ported merely to give Windows users a better experience on the Internet. It was ported because it was seen as a viable way to show Windows users the way of Apple. Many people refer to this type of thing as the iPod effect, iPod halo effect, Apple Envy, or some sort of variant. Hitting Windows users with an application they can use for free, an application they could theoretically use every day, is one more step for Apple in an otherwise Microsoft-oriented world. A Web browser can be a very personal choice for a person, and Apple wants people to choose them.

Firefox has been ridiculously successful in providing people a better way to browse the Web. Apple has seen this success, and in my opinion, feels it is now the best time to capitalize on the idea that Internet Explorer is not the end all be all Web browser for Windows users. It is their time to show that they’ve got a solution as well, and their solution has anti-aliasing in menus to boot. Let us not forget there are also snappy page loads, a small footprint, and that spiffy interface! Safari is an interactive advertisement for Apple, and porting it to the most widely used platform gives the application a very big stage to present itself.

The newest battle in the Browser Wars?

Personally, I’m a big proponent of open competition. If there are a number of high quality Web browsers openly competing to be the best, I think it will force browser manufacturers to provide the best product they possibly can, or else their user base will shift to a provider who can. A very large number of people have embraced Firefox as an alternative to Internet Explorer after it has proven time and time again to be a sub-par Web browser.

To this day I discover quirks and bugs that have continued to prevail in Internet Explorer 7. While it is a slight improvement over IE6, the entire Internet Explorer family of products is truly a sad state considering what is being released elsewhere. At the very least, it’s my hope that Microsoft starts to take their browser more seriously than they have, and the release of Safari for Windows will help to try and make that happen.

The true issue to keep in mind, however, is that the average reader isn’t going to care whether or not you were able to take your design to the next level because you didn’t have to worry about z-index bugs, the only thing that gets noticed is when things go wrong. Many of the drawbacks to Internet Explorer are not seen, heard, or cared about to many people other than Web designers and developers. What does get noticed is a better feature set, a cooler interface, and any performance differences that may be in place. Superior applications will reign supreme when it comes to that criteria, which will eventually decide a winner in any sort of Browser War.