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.
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.
Comments
Very good article!
I agree completely. If a user is browsing a website with IE 6, they should still be able to access every part of the site without a problem. Completely blocking should be out of the question! It seems the arguments made are due to developers being lazy. Like you stated above, over time you remember what problems you faced and how you fixed them. That way you don’t fix it every-time. I know that when I code, I’ll foresee problems I’ll have in IE 6 and either fix it then or in the IE 6 stylesheet.
Degradation is the best way. Forcing myself into the mindset that a single site won’t look exactly the same in every browser or operating system, took a while. It was hard to do but, was worth it.
All I can say is, developers need to stop being lazy. Just be glad were not forced to support all mobile browsers! 🙂
You “aggressively” imply that designers who choose not to support Internet Explorer 6 are too ignorant, or too lazy, to do so, which is a specious argument. Hacks dealing with the kludginess of IE6 have been documented and disseminated for nearly a decade. Aside from the moral-philosophical reasons for wanting to eschew IE6, there is real cost in implementing and maintaining–particularly in maintaining–each and every hack you put into your codebase. And you stated yourself that you actively avoid markup and styling that will break in IE6, meaning that you willingly bind your hands as you implement.
Effectively, you’re arguing for including the old standby hacks but doing so poorly, which seems to me the worst of both worlds. If accessibility is truly your goal, and you’ve created a progressively-enhanced design, then why not simply own up to the mire that is IE6 and serve it a no-CSS, no-JavaScript version of your document and let it stand at that. And for those web applications that have chosen to not implement complete accessibility (and there are valid reasons for doing so), broken JavaScript can easily yield a broken application. Letting it simply fail in IE6 is not an option.
I do agree with the notion of aggressive degradation, but I don’t think this approach hits the right spot on the cost-benefit curve for a lot of people, myself included.
@Matt Yoho: While I appreciate you taking the time to provide your feedback, I think you misunderstand the point I’m trying to make. I absolutely do not feel that because a designer may elect to roadblock IE6 he is too ignorant or too lazy to do so. That’s not the case at all. In fact, I believe that if a designer has elected to take such a stance, he has weighed the pros and cons and come to that decision in an educated fashion. While not always the case, I like to think that’s the majority. There are countless designers I know and look up to that have elected to roadblock IE6 and I would never in a million years accuse them of ignorance or laziness.
That said, I’m not convinced that by forcing IE6 to show the lowest common denominator of a document you are increasing implementation or maintenance costs. Quite the contrary. If your foundation is strong, there should rarely be a case for extraneous maintenance. Instead, the document will continue to work with the lowest common denominator. I don’t suggest employing any hacks, instead I’m suggesting the provision of a literal crutch for IE6 to somehow manage the display of a document.
IE6 is perfectly capable of handling basic styles, so why force your visitor to read something that is blatantly different as opposed to slightly so? Regarding Web applications, this solution shouldn’t even be on your radar. I didn’t imply that “letting it fail” was ever an option, instead that you should force a graceful degradation should the situation have such a requirement.
I’m very interested to hear more about your views regarding the major lack of cost-effectiveness with such an approach, would you mind elaborating should you get the chance?
Nice write up and I feel its how we do things at the agency we are at. We are unfortunate/fortunate (depending on your stance) in having a client who has a whole office on IE6 and is very large. They text and approve work on this browser though some are now getting IE7. It means we have no option than to support to some level. Using conditionals and alternative methods such as serving gifs over the PNGs etc and always having a none javascript alternative regardless have always proved a winner for us.
I think what a great deal of designers who take a very agreesive stance on IE6 need to probably see is the bigger issue around IE6.
I was one who had nothing but disdain for IE6 users until I was shown the figures behind a large corporation (think worldwide probably with staff and office infrastructures in the thousands) upgrading all machines and IT from IE6. When you consider the cost they spend on making their sites accessible on that version with an above plain styles version you can see its more sensible for us to do the fixes.
There is also the cost of schools and colleges etc. Changing IT in these environments is a major financial decision right now and not something they will do simply for a site. There was recently a friend of mine who works for a council who are rolling out a UK government funded application site for students to use to prepare for University, Bearing in mind this was going to schools and colleges it had to work on IE6 and was broken to the point of hindering the users. The firm in charge of delivering the solution tried to say “we don’t support IE6” which in their game – educational solutions – is totally unacceptable.
[…] This post was mentioned on Twitter by Jason Karns and joseallona. joseallona said: perdón la monotonÃa http://bit.ly/aatV2 pero es un tema que me preocupa. […]
Jonathan,
I think we’re pretty close in our thoughts on the trade-offs designers face and weigh out when developing a site. I took exception (possibly too much exception) to what I read into your post that seemed to imply that, because supporting IE6 can be done, it should be done, and further I got the impression that you thought it a sub-standard practitioner who wouldn’t do so. But I may well have read in too much. Maybe I was just in a pissy mood this morning. 😉
But still, I do think we disagree about the cost of IE6 support. Clearly, constructing those crutches and shims to keep it from blowing apart require time to build, and even if you maintain a set of files and techniques that you can reuse, you must maintain it, and tailor it to each new site. With every new feature or new design, you need to consider whether your library or workarounds will support it, and if not, whether it can be done and how you’ll go about doing it. There is a reason why large sites like Digg and YouTube, who clearly have plenty of resources at their disposal, are declaring the ongoing maintenance cost of IE6 to be too high. For smaller shops, and I personally live in this category, that incremental cost can become very high indeed.
But certainly, I am biased against IE6, both from an engineering and project management point of view, and from a philosophical one. I’m one of those “political-activist” types on this issue. I resent the mistakes of the large enterprises that invested in proprietary solutions and locked themselves in, via ActiveX or what-have-you, to IE6. I view IE6 as a yolk around the progress of our industry. So I’m not being entirely objective in my reasoning for disagreeing with you.
This is betrayed a bit in my claim that you should send unstyled documents to IE6 users. On the one hand, it’s an extreme position. Yet, strictly from an accessibility perspective, and assuming a reasonable semantic layout, it’s not all that unreasonable when you consider it. You will have delivered that content to the end user. Not with the presentation that was painstakingly designed, no, but it will be no less available to the user. If you’re choosing to triage the downgrade in styling for IE6 users, why not consider just what is essential to the experience for them. Is it the information, or the presentation? For many applications, it will be the former, and in that case, is the cost of additional IE6 implementation worth it? Are we valuing the sunk cost of the initial design so much, and the design itself as a sacred product, that we must try our best to defend it against the mess that IE6 will make? If so, what ideas or features will we choose to leave behind in order to make it so?
(I should say that, when I think “accessibility”, I think screen readers and mobile devices, not standard but downlevel browsers. I would much rather invest in a custom mobile experience than in an IE experience that approximates more standards-compliant behavior. I’m perfectly willing to add friction to an IE6 end user in the hopes that they will upgrade and move on.)
I do believe in graceful degradation, and I do believe in aggressive degradation–very aggressive, as the case may be!–for downlevel browsers. For many, many sites and applications I think you are spot-on in your approach. But it’s a business decision, and the choice to go the other way can be entirely valid.
Ultimately, in my projects I must weigh the time and effort of IE6 support against the opportunity cost of implementing new features or improving infrastructure, and I will choose something on the latter side every time. But it would be foolish of me to claim that everyone should see things my way.
Thanks for the article and the discussion. And sorry again for the name-calling. 🙂
@Matt Yoho: There’s no need to explain your reaction, in my opinion you replied with the candor of anyone with an opinion, and I truly appreciate you taking the time to thoughtfully reply to something you strongly disagreed with.
I completely sympathize with your explanation of the extra time necessary to both establish and maintain an “alternative” version for IE6, thank you for simplifying and explaining so well. I clearly see what you meant now, and understand that it can snowball into an exorbitant amount of work for such an otherwise unnecessary reason.
I too share your bias against IE6. I, along with every other HTML5 CSS3 lovin’ designer out there, hate the thing. I wish it never existed and it saddens me that we all have to deal with it for the next number of years. It’s a depressing thought, it really is.
You’re absolutely right; if you deliver a completely unstyled version of your document to an IE6 user, the important part is the information retaining its accessibility, which is why I prefer that method to something more abrasive such as a roadblock forcing the viewer to upgrade his browser.
I think at the end of the day our opinions on the matter are quite close, but just inches away from one another causing you to fall on one side of the fence while I on the other. I really appreciate you taking the time to explain your stance in such detail, as I’m thrilled to have such an excellent look on the other side. I’m glad we were able to touch base on the issue today, your comments have made the article exponentially more valuable. Thank you.
Totally agree on that. Degradation is the better to work with IE6. The “pixel perfect syndrome” is hard to loose but once you pass that point you can be free!
Honestly, I’m beginning to think that the divisiveness on this issue relates to how long web developers have been working. Those of us working since say IE3 or IE4 have lived with the situation longer – we know what IE is and is not capable of, and it barely adds to our development time to support at least a reasonable facsimile of the site for IE6 users. 95% of the time, I know, without even testing, which lines of CSS are going to cause an issue in IE and take care of the fix as I’m writing the code. IE6 celebrated its EIGHTH birthday last month. It makes me feel a little old to say it, but I’d be a pretty poor web developer if eight years experience in something hadn’t taught me anything. I’m still grateful IE6 didn’t use IE 5.5’s box model.
Those who are newer to web development, who maybe got started after the release of IE7, learned in newer browsers with better support for everything and only see IE6 as this anchor that drags everything down, makes their lives miserable and keeps them from realizing the true potential of the web. To them I can only say – have patience because all browsers fade from use with time and learn, really learn, progressive enhancement. You’ll save yourself a lot of time and frustration and have a better starting place, not just for supporting IE6, but for supporting a myriad of mobile browsers, accessibility and search engine optimization.
Nice article! I agree with it completely.
I do not think the browser war is our battle as well. Web designers and developers should not be dictating what is on a user’s computer. That is not our job. Our job is to provide content that the masses can enjoy and use. I do wish all IE6 users would upgrade browsers, however that decision is up to them.
What are your thoughts on developers needing to create modern web experiences with IE6 being the majority? Corporate environments for example, may want a modern experience for an internal application. However, the entire company is still on IE6. What is the answer here?
Time and again discussions like this end up being decided on a per project basis. I do a lot of in-house projects with a controlled audience (no IE6 worries). However, I developed a project this year that is worldwide. You bet I coded it for IE6. All its style, javascript, and everything else was tested in IE6 before launch.
Do what you have to do for whatever the project needs are.
Horay for a mature way of looking at the problems related with IE6. This is a great article.
Those people who add the fake ActiveX “You need to upgrade your browser” thing to IE6 visitors are misleading the person. I find this the easy way out.
It’s nice to find someone thinking about an appropriate solution.
Very good points. I guess graceful degradation is the path to the future. The differences between browsers are enormous, and the market should accommodate to this situation.
Thanks! You made me think 🙂
I don’t think IE6 is something to be hated. It’s old, sure, but I think the web development community would relieve a lot of stress and angst to imagine IE6 is the old klunker in the garage you wish you could replace, but just don’t have the money.
We should keep in mind that even after IE6 finally dies, we haven’t solved our problem: not all users upgrade their software. The IE6 problem is decidedly not just about IE6.
I think you, Jon, are contributing greatly to the community with articles like these. The web development community needs to create concrete strategies for dealing with the constant change in technology and backwards compatibility.
[…] Explorer: Aggressive Graceful Degradation – Sehr guter Beitrag über den Umgang mit dem IE6. Der beste Fix für IE6-Probleme ist […]
[…] ist ein Plugin für den Internet Explorer und veranlasst diesen – bei gesetztem Meta-Tag – Webkit und V8 zum Rendern der Seiten statt der eigenen Engine zu nutzen. Prima Sache, könnte man meinen, jetzt ist die Zeit vorbei, in der Webdesigner eine Extrawurst aufgrund eines uralten Ungetümes braten müssen. Die Zeit wird es zeigen. Letztendlich hängt es von der IT eines Unternehmens ab, ob diese den Einsatz des Plugins duldet oder nicht. Meiner Einschätzung nach wird man nach wie vor nicht um die IE6-Extrawurst herum kommen. Ein andere Art mit dem IE6 umzugehen zeigt dieser Artikel – How to Handle IE6: Aggressive Graceful Degradation. […]
IMO developers should stick to web standards and not deviate from them because of some broken piece of software. However in the real world that simply doesn’t work.
For quite some time now the company I work at separately bills the time time it takes to implement IE6 support. Its up to the client to decide how far we take that support (just make some alternative style sheets or try to replicate everything we do in modern browsers aswell) since they deciddd what the budget is on a project. Besides it doesn’t have to be hard to support IE6 if you use progressive enhancement. Accessibility is key, fancy effects are just extra’s but not really necessary to serve the content.
[…] How to Handle IE6: Aggressive Graceful Degradation – Monday By Noon – […]
In our contracts we specify which browsers are supported. Believe it or not: ie6 was on the list until recently. We kept it like Jonathan wrote in his post: We support(ed) ie6 because of our goal for accessibility and backwards compatibility.
We now explain our customers that the web will never evolve if people stick to an eight year old piece of software. eight years old! that’s way more than half the age of the commercial world wide web! But then we still strip the website down without JavaScripts, without transparent PNGs, etc.
well. there are a number of ways to write the markup for ie6 without any compromise against other browsers. it’s more like a best practice. and there is pngfix too.
there is good part of IE6. it helped mozilla to rise. i mean mozilla essentially hijacked ie6. and it was damn easy.
however we must take into consideration those 12% “special” people who are still using it. and i am beginning to think that those 12 are we, who must test after every line of code. 😛
the sites that i worked on always look a bit better in FF.i tend to make it pixel precise there but the overall difference is not observable, more like suggestive [the page appears unordered, you can do this with some 1 pixel facing margins and borders. input elements are doing it automatically]. it’s my psycho-warfare against IE in general.
best part: it’s subtle enough so i still have a job.
My design aspirations and internet ideals mean nothing to my boss. My boss thinks in terms of customers and money, rightly so.
Passionate please about ease of maintenance or fancier graphics mean little to my users, who in all likelyhood, just want to complete task A, B or C. I’m building the site for them, not me.
My wishes to leave IE behind are tempered by real usage statistics that say my company makes millions a year from IE6 users. We still make a gob’load from the IE crowd.
To find a graceful solution within the field set before me is the challenge. Limitations are the soil from which creativity grows.
Yes, I still wish IE6 would die.
[…] schöner Artikel bei Mondaybynoon darüber, wie man als Webdesigner mit dem IE6 umgehen sollte. Und ich sollte vielleicht […]
This is a regular argument in my office between my managers, my colleagues and I, and often ends up with one of us walking off to cam down.
It’s such an annoyance that we have to support this antiquated technology, but as usage statistics dictate, we must.
I’ve always fallen on the side of the fence that says to hell with it, drop support, as I am a bit of an activist, however recently (with the help of articles like this one) I’m beginning to change my views. The less fixes we have to do the better, however something readable and useable has to render in IE6, so I opt for the ‘simple version’ approach to my designs. They look simple in all browsers and convey the content, as after all, content is king!
I use the MooTools framework for my javascript, which has very good cross-browser support and have yet to find a function that doesn’t work properly in IE6, so for now, I don’t remove js in IE6… For now…
As for CSS support, I have (and still am) learning techniques to render something ‘almost’ the same in IE6.
This is a great article, and your extra content links are also very good reading. I shall be passing this round the office!
I use the IE8 simulator script and PNG -trans fix for lesser versions of IE. I include the script because it’s easy, but it’s important to remember that IE6 users most likely have an older machine where the fewer effects are drawn, the better.
A hot topic around our company too. But it all depends on the usage report. If your company is targeting everyone and you have an ecom site, design to get them through checkout. Accept some of the styling will not be in 6. But if you are developing a site that is going to target advanced users forget support for IE6. Every time we include support for old technology we put the brakes on advancement. Anyone here designing support for version 4 browsers? Anyone? Don’t be shy step up now. Hell no we left those crappy browsers in the dust. But it took years of painful effort. The faster we (that’s right its us not them now) make 6 obsolete the faster we can move on. I actually like MS for its efforts in supporting the demise of 6. Need to make 6 work with new technology, need a plug in, need to download it, MS just points you right over to 8. Soon 6 will join 4 and then it will start all over. I predict it will be with Flash on the phone. Stay tuned, more wars coming to an electronic device near you.
Even in the handful of months since this post was originally written, the culture behind what drives modern websites has helped push the envelope more and more. So I think the time has come where we can take your approach, Jonathan.
Like you, I’ve seen the extremist camps who call for the execution of IE6 and those who find reason to continue to support it. I’ve seen in the past at my company people who say we need to cater to IE6 because we believe the majority of our end-users still use it. As a B2B company, we know that our end users are shackled by their IT departments who see that IE6 still works for them or, if it doesn’t, the IT guys are themselves limited by funding to upgrade hundreds of PCs.
I agree with David and many others here that it is time to stop catering to IE6. But in order to do that, the biggest step (especially for web developers who work for the B2B industry) is to educate our clients and customers that, although the marketing department or end user may be using IE6, all those cool new features they want will NOT work. All those drop shadows and bursts and rounded corners will NOT show up. If they realize they are using an old browser, they may consider upgrading their own machines or, if they have the power, to call for the upgrade of the whole company’s slew of machines.
Someone mentioned above that web developers might call for the end of IE6 because they are lazy. It’s not that, although it IS frustration. Web developers live their work and know the minor details whereas customers would not. Most people don’t even know that there is an option to disable javascript, for example, nevermind knowing what that even means. So although it might be frustrating to educate our clients, telling them the ROI on developing high-end features for a low-end browser is little to none, taking the time to educate them from the get-go will save a lot of frustration down the road.
STAN
“I too share your bias against IE6. I, along with every other HTML5 CSS3 lovin’ designer out there, hate the thing. I wish it never existed and it saddens me that we all have to deal with it for the next number of years. It’s a depressing thought, it really is.”
The problem is, if we keep making the sites look “right” in IE 6, IE 6 users will never upgrade. Why would they? My preference, if allowed, is to just serve up the content, simply styled with Andy Clarke’s “Universal” CSS (because I am too lazy to create my own), perhaps with a kind message urging the user to upgrade. If the user needs to use IE 6 for internal company sites, fine. Do so. But they should be able to browse the rest of the Web using any of the numerous free, modern, stable, safe browsers.
Incidentally, I looked at this page in IE 6. It’s very broken. Transparent PNGs haven’t been replaced/removed and the layout is jacked. Maybe that’s a “haven’t gotten around to it, yet” issue. =)
Education is absolutely a big deal, and a huge part of pushing things forward. It’s important to do our best to help clients catch up with the details on getting the most of their new website. Many businesses will also respect the fact that financially, it’s not in their best interest to worry about such things concerning their ROI as it is. That is of course unless their existing metrics say otherwise. Thanks for the solid notes!
I think an important thing to consider is that if (mostly) anyone is given the option to upgrade from IE6 probably would. I have to believe that the majority of the remaining IE6 population exists simply due to lock in via IT department. After all is said and done, the most important thing by far is to simply make sure the site is accessible and usable. Your last note about this site ties in another point, it all comes down to audience. I’m sure you only checked it out in IE6 due to the topic matter of the article, and that’s great, but I purposely haven’t even seen this site in IE6 because of the readership. To be honest I’m quite sure it’s an epic disaster in IE, but I don’t let that bother me simply because the only people using it are, like you, designers checking to see if I eat my own dog food 🙂 Aggressive graceful degradation makes sense for every one of my client projects, but the metrics here tell me I don’t really need to even consider it.
I’m sorry, but (jackhole tone not intended) I really hate that IT excuse. I can’t believe it’s still being used as an argument. I put it up there with “it’s too expensive to upgrade everyone’s computers”. If anti-virus software can be kept updated, so can browsers.
Any IT department that knows what it’s doing and is worth its budget would not allow–let alone force–its employees to use IE 6 as a general Web browser. It’s universally known as the most insecure browser currently in use. National governments, security experts, even its maker have acknowledged this and strongly recommended its discontinued use.
That aside, if people at work are using the browser for personal reasons, what’s important is the information (“After all is said and done, the most important thing by far is to simply make sure the site is accessible and usable.”). They can wait until they get home to view the “pretty version” of the site. Chances are really good that they’re blocked from Facebook, Gmail, and any other sites that can’t simply serve up unstyled content. If seeing unstyled content is really that distressful, they can get an iPhone, Android phone, or Palm phone.
For those using IE 6 as a professional tool, they are using a browser that is slow and unreliable, keeping them from doing their jobs efficiently. They should lobby to have a modern browser available, but if everything “works”, they have a harder time with this argument.
I misunderstood your statement in this article of “I (and my company) support IE 6.”. I guess by that you meant you (personally) support it philosophically. But yeah, “dog food checkers” explains the 5% usage on MBN. =)
I only bring up that ‘excuse’ as it seems to be a common response to the “why are you still running IE6” question. Personally I agree. If an IT department can update software, they can update a browser. If you’re using software that requires IE6, ditch that software. You can’t run on that for the rest of your company’s life. Things are progressing to IE6 being a thing of the past. My major concern, however, is to skip stressing about it and simply force IE6 to render the bottom line.
When I said that we support IE6, that’s all I meant; we support it in the sense that your PNGs won’t be gray, your text won’t be overlapping itself, and the page will behave properly. It might look like a significantly different page, but it works all the same. That’s the extent of our support. On personal projects though, as you can see, I don’t raise a finger most of the time.
Yeah, I did a bad job with that first paragraph. I meant the excuse itself, that IT depts. stuck on IE 6 still exist. It wasn’t directed at you. I’m trying to give their users as much ammunition as possible to get it removed or an alternative supported.
[…] this is not an approach I take to client sites or important functionality. I believe in the Aggressive Graceful Degradation model where the site is still accessible, readable and usable, but if Internet Explorer users […]
[…] How to Handle IE6: Aggressive Graceful Degradation (Monday by Noon) […]
[…] How to Handle IE6: Aggressive Graceful Degradation (Monday by Noon) […]
[…] […]
[…] How to Handle IE6: Aggressive Graceful Degradation (Monday by Noon) […]
[…] […]
[…] time ago, I ran across this article: How to Handle IE6: Aggressive Graceful Degradation, by Jonathan Christopher. What I took away from the article: We shouldn’t be killing […]