As web developers, to stop special scripting for ie6 is our first step to move on. MAN there are too much fun using new tools and scripts, why we should waste time fixing Microsoft's bugs!

1. They work in a company that have old version of windows (and I mean even windows xp with no updates) and don’t want to update windows, don’t understant the reason but that is their problem

2. The users have no idea how to upgrade, have no idea how to download other browsers have no idea what internet experience means
So for this users it’s a very good idea to put a disclaimer that lets them upgrade or download a better browser.

3. They have a crack copy of windows and can’t upgrade.

4. I did say there are only 3 but this is a special one:
are too lazy to give a click

So yeah let’s beat our head against the wall to make special code for this special handicapped users

This is something I’ve been willing to do for quite a long time now: leave the content intact for IE6 (and, at the same time, create myself a pretty print stylesheet for other browsers) and have the design bits handled by modern browsers properly.

There’s two major problems here, though: The first one is that clients do NOT want this alternative most of the time. Understandable, but annoying.

Second one is that IE6 is not THAT broken that it requires a completely different stylesheet. Yes, everything is emssed up and you probably need to spend a lot of hours making it look properly, but it’s still not as broken as to completely drop support for it.

It’s a hard choice, and it needs to be addressed properly. Sometimes you’ll have to support IE6, sometimes you won’t. That’s life.

I’ll even offer that supporting a browser with such deficiencies has a subtle but aggregating effect on user trust w/regards to the web or my website. So if I’m the security department of, say, Facebook – I’ll be looking to discontinue support of ie6 solely to maintain the trust and perceived integrity of my site alone.

Sure, they have the option of just the html – and I’m a big proponent of semantic html – but a lot of applications are beginning to move away from the old page-based semantic-content paradigm.

If I consign IE6 to the same level of support that I give to lynx then I am essentially dumping all testing of IE6 – but to ensure that it doesn’t try and fail to execute any javascript then browser sniffing is a reasonable option.

And @DZ – I haven’t used facebook in IE6 for a while, but for a long time they simply did not support it – especially around the time of the redesign.

The way I always handled the netscape problem was to create a baseline CSS file: background color, type, etc – the stuff you can do in 15 minutes and not as much override as augment for modern browsers.

Then, @import the more advanced stuff.

I think you can accomplish a lot through that approach, without having to do the work for IE *plus* adding a banner or nag.

It’s not so much about ignoring it. After all – as I conceded in a prior comment, you could always display a general purpose, none-IE6-specific message to users of *all* outdated user agents saying, “For a richer experience, view this document in a modern browser like FF or IE8.”

It’s the banner and nagging – especially when added to an already functional IE6 site – that screams “bandwagon” and probably won’t be effective. A full interstitial roadblock is just brand suicide and requires work for three user agent groups:

1. Modern, rich browsers.
2. IE6 – singled out for no good reason
3. Outdated or less-rich user agents

I bet it’s a safer business decision, and definitely more in line with your philosophy of doing less work around IE6, to simply fold IE6 into the outdated UA pool and move on – with or without a generic message for all non-rich UAs.

The gamble is up to each company, of course. I just don’t want anyone thinking that an effort made specifically for IE6 counts as less work.

Back in the old days, we were able to effectively “hide” our new fangled stylesheets from NN4 by attaching them via the @import property, which it ignored. We did not, or at least I did not, code a specific style sheet just for NN4, or other non-standards-sort-of-compliant browsers.

Generally, my NN4 style sheet, as well as many other’s I can remember, contained a rule to specific show and make prominent a note about the need to update the user’s browser. And that was it. We would hide this block in the style sheets aimed at modern browsers.

There was also a very concerted campaign (WaSP, etc) to encourage and advocate for the use of modern browsers. Badges like they were going out of style, posts, advocacy groups petitioning the browser makers, etc etc.

The fact the campaign worked should speak wonders for how we should treat our current predicament. Hell, I’m of the mindset that every 4-5 years, we’ll go through this whole song and dance again.

Regarding the business decision:

After all, if those people aren’t worth addressing or supporting, why would you care what browser they use?

Because they aren’t worth addressing not because of some inherent flaw in their personalities or who their friends are, but because they’re using an old browser and costing me time. I don’t hate them, nor am I ignoring them, I just can’t be bothered to support their browser. But hey, if they upgrade we can all be friends again! And I really really need friends. It’s very lonely here.

Would their upgrading to IE8 make them a thriving part of your customer base?

Who the hell knows. Maybe.

If so, is the effort of upgrading the best place to spend your time/money?

Who the hell knows. Maybe. The message is a one shot deal, that I can throw up and be done with. If it encourages some user to upgrade, there is a good chance they were honestly interested in my site or business enough to endure the hassle. And maybe once they’re upgraded, they’ll come in and buy a bazillion million widgets from me.

It’s a gamble.

Have you completely maximized your main audience?

Probably not. Hence why I’m not spending time worrying about dealing with a minute percentage of my audience’s poor browser choices. I have other people to tend to who are demanding all sorts of weird things I need to go spend time on.

By the same token, I don’t know that these IE users wouldn’t be great customers, if only they upgraded. So I send a little note and see if they bite.

And if your goal of selling browser upgrades is more than dogma and is about converting the last outliers on the web who aren’t using your service, which of the four options that I listed will you take to message them?

Anything but option 4, which basically presents a broken site, no explanation for why it’s broken, and leaves it as an exercise to the visitor to sort out that they’re seeing Times New Roman and lots of unstyled ULs not because my site is broken, but because their browser is.

In terms of a technical solution, Toby, I think you’re right, and it’s a very elegant and simple way to handle the IE6 problem. It just doesn’t so much handle it as ignore it and hope’s it goes away.

I’ve been thinking about that angle a bit. I understand the gut reaction there, but I’m having a hard time reconciling a few thoughts.

First, the obvious: any existing IE6 users won’t get that impression. They are already using your site (in IE6 no less), so a banner telling them to upgrade their browser seems a little misplaced. “Hey, upgrade, because, even though I already did all the work to support IE6, or kept my UI compliant with IE6, I am on a mission to spread the gospel.”

For brand spanking new users on IE6, or for all users after a redesign, things make more sense. Still, what are your options?

1. Completely block access, interstitial-style. Show them a nicely-designed, friendly upgrade message and refuse them access to content until they upgrade. This seems like a lot of work. Probably more work than serving them a basic, but attractive stylesheet.
2. Design something that works with IE6, but show them a banner at the top of the page urging an upgrade. This is the same situation as with existing users: you’ve already done the work of supporting IE6 at a design level, so the upgrade nag message seems like misplaced effort.
3. Serve a “broken” experience but with an upgrade notice. If you’re looking to make a good impression, this seems like a bad idea.
4. Serve a plain stylesheet with basic brand guidelines in place (color, type, legibility) as you would do for a screen reader or other outdated user agent.

If you have more advanced features, or want to tout your fuller design experience, I can concede that option #4, which is what I am advocating, could be used to let new users know there are alternate, richer views of the content for modern browsers.

A lot of people (like Jack at Big Contrarian) talking about this post say IE6 users aren’t worth the effort to their businesses. I don’t care whether that’s true or not in any particular case, but if you take it on faith, my option still seems to be preferable.

After all, if those people aren’t worth addressing or supporting, why would you care what browser they use? Would their upgrading to IE8 make them a thriving part of your customer base? If so, is the effort of upgrading the best place to spend your time/money? Have you completely maximized your main audience? And if your goal of selling browser upgrades is more than dogma and is about converting the last outliers on the web who aren’t using your service, which of the four options that I listed will you take to message them?

I can’t help thinking this whole “Ban IE6″ banner thing is impotent dogma lacking in real business modeling. Next up, we all change our Twitter icons green to save Iran!

Back with Netscape 4, the winning method was to serve a plain “nn4.css” baseline stylesheet to people and serve more advanced styles and scripts to modern user agents. Turning the web “plain” is enough vinegar to convince the stubborn to upgrade while being decent to those with no choice in the matter.

To quote Jack, “Why this time is so magically different is beyond me.”

IT depts sometimes can’t help it. I have friends who work at places where *corporate* technological progress is glacially slow. Especially in large companies that exist in non-tech sectors. IT personnel *personally* want to upgrade, don’t doubt that. But personal — or even departmental — wants and needs don’t always align with corporate budget and priorities.

@peter “But with more and more browsers supporting things like canvas and video, and more and more javascript reliance, it’s getting less and less feasible to provide even ‘content support’.”

If Facebook, who powers nearly everything with javascript, can offer a relatively content-rich experience for browsers without javascript, you can too. Just like all support, ‘content support’ has gradations. You don’t need to have or present content the same way for everyone.

You’re already presenting content different in various accessibility contexts. This is just another view of your content you need to consider. Maybe you decide it’s worth it, maybe not. But don’t dismiss the possibility out of hand.

And to nitpick on HTML5 video for a second, even without IE6, you’ll need to consider support. Since HTML5 (currently and for the foreseeable future) does not specify a container format, the typical site serving HTML5 video will need to encode their content in mp4 *and* ogg *and* probably wmv to maintain comparable compatibility with Flash players.

At that point, creating a flash player fallback that reads H.264 isn’t much further down the path.

Handing IE6 users content (whatever level of “design support” your client decides to pay for) is most important. There are plenty of users without a choice. Why block them from the content? All content for all user agents — always what I strive for. The experience may vary.

Excellent, pragmatic post and what I teach when I speak and train.. :)

Yes I could have fixed it, no I didn’t want to, no I don’t think the client should bother paying to support any particular browser only particular levels of standards compliance.

If canvas elements are vital to your content and it would be misleading or unacceptable to serve the textual and image content without those elements, by all means, shut out IE6 at the gate.

My point is simply that you shouldn’t target IE6 and its users, but rather treat the entire *class* of legacy or handicapped user agents consistently.

If you have a heavy JS/AJAX application you probably already gave up on printer, lynx, screen reader, feed, and google support. Just toss IE6 into that class (along with NN4 and IE4 and Mosaic and…) and treat them all as below your baseline.

Calling out IE6 as a special case and talking down to IE6 users is the problem. The solution is to just toss it into the same bin as other baseline (or, in your case, below-baseline) user agents.

For (what I hope is the final time!) I am not saying to bend over backwards for IE6! I’m just saying that, if you don’t want to put in the work and make the concessions required to support it graphically, treat it however you’d treat any anonymous, low-powered user agent. If you’re doing it out of novelty and not necessity, I also recommend modeling the impact to your user base.

Simple!

They want people to stop using it, instead of just refusing to design for it for 2 reasons (and maybe more):
1. As web designers/developers, we are passionate about people having a beautiful and pleasant web experience. If we just stop developing for IE6, everyone who hasn’t dropped it may have a lesser experience, which just wouldn’t do.
2. Many of them may be forced to support IE6 by their respective powers-that-be, so the only way they can stop actively supporting (designing for) it is by getting a significant amount of people to stop using it.

I agree with you in general. I am never a fan of over-zealousness and pushiness, but sometimes that’s the only way to get things done.

Thanks for the thoughtful article.

Oh, and that speckled background had me wiping my screen for a good 5-10 seconds, trying to get the dust off. :D

There needs to be a strong incentive to upgrade.

You and Rob are reacting the the headline and ignoring the content, it seems.

Rob – unless you’re forcibly *blocking* IE4, you are *supporting* it.

It’s all about the definition of “support” and the abandonment of dogma, fellas.

No, I’m sorry, websites are software. While I completely understand your perspective here, if you are using out of date technology to access that software, your experience should be, if not completely curtailed, then limited so that the engineer doesn’t have to build in code that will, inevitably, make the experience slower and buggier for *everyone*.

If you think we’re just patronizing or dismissing IE6 users, you’re missing the point. As of the 27th of this month, IE6 will be 8 years old, just a little bit older than Windows XP–and even Microsoft isn’t supporting that operating system any longer. And they wrote the damn thing.

Reclassifying IE6 into the category of feed readers, screen readers, and printers is a perfectly viable solution.

Oppose that to the childish antics behind blocking content based on user agent.

In each case, you get to provide interesting experience design for modern user agents, but only by reclassifying IE6 for *content support* do you also retain (some portion of) the IE6 audience.

Obviously this is a very dynamic issue that requires a personalized approach for each individual organization, but the bottom line is that an 8 year old technology can no longer remain an influencing factor if Internet experiences and interactions are to evolve further.