Do You Plan to Support Ie 6 on Your Future Projects

Do you plan to support IE 6 on your future projects?

If it's a paying gig, tell them you'll charge more unless it's an assumption going into the project. That's the only way it's worked out for us so far. I'm all for backwards compatibility but the amount of money wasted on supporting IE6 for most websites/applications is just ridiculous.

Should we support IE6 anymore?

This depends so much on the context of the application, and of its users. There are two key aspects: what browsers are your users using; and how important is it that they can access/interact with your site.

The first part is generally easily establish, if you have an existing version with stats (Google Analytics or similar is simple and great) or you have access to such data from a similar app / product.

The later is a little harder to decide. If you're developing a publically availalbe, ad-sponsored site for exmple, it's just a numbers game - work out how much of your audience you lose and factor what that's worth against the additional development time. If, however you're doing something specifically at the request of a group of users - like an enterprise web app for example - you may be stuck with what those users are browsing with.

In my experience those two things can change significantly for different apps. We've got web apps still (stats from last week) with close to 70% IE6 usage (20% IE7, the rest split between IE5.5 and FF2) and others with close to 0% IE6. For relatively ovbivous reasons, the latter are the kind of apps where losing a few users isn't so important.

Having said all that, we generally find it easy to support IE6 (and IE5.5 as others point out) simply because we've been doing so for a while. Yes, it's a pain and yes, it takes more time, but often not too much. There are very few situations where having to support IE6 drastically changes what kind development you do - it just means a little more work. The other nice benefit of supporting it (and testing for it) is that you generally end up doing better all-round browser and quirks testing as a result of the polarity of IE6's behaviours.

You need to decide whether or not you're supposed to find workarounds, based on the requirements of your app/product. That's it's IE6 isn't really that relevant - this kind of problem happens all the time in other situations, it just so happens that IE6 is a great example of the costs and implications of mixed standards, versioning and legacy support.

Ethical Dilemma: Should I still cater for IE6 as a web-developer

One point con-support of IE6 is that
Microsoft no longer offer support for
it, and it is considered a defunct
browser, so why should I waste my time
catering for it.

Because it's not Microsoft you're catering for, or people who consider it a defunct browser, it's people using the browser, aka your customers. By all means, don't take on customers who have a requirement that you support IE6 with websites you produce, that is your chocie. But if you're getting paid for it, I'd hardly call it "wasting my time" =)

How much time and effort do you spend on IE6?

According to some - browser - statistics, IE6 market share is still bigger than Chrome, Safari and Opera together, nearly as much as IE7.

Unless you target a very specific market (indeed check your stats to know for sure), neglecting to make your site looking at least decent with IE6 seems a bit foolish today...

I won't take the road to tell visitors what browser to use, for sure!

Save me from IE6

Quite a difficult task to do, as there might be other reasons why they are using IE6 until this date (other, conflicting software which relies on IE6).

The first thing to do would be to identfy the problem that stops IT from doing the migration - if it's not lazyness.

• Maybe it is easier to ask them whether they would consider an "alternative browser" to be installed (which wouldn't affect the IE6 installs). But most administrators don't like that idea, because Firefox doesn't share data/configs with Windows Servers, but trade-offs might be made in favor of money.

• Should there be no real obstacle, you might show them a real-life example how an average day for an IE6 developer would look like.

  1. Choose an UI-feature (combine all merits of IE6 to create one) that will work to cause the required issues for the next few steps.
  2. Show them how everything looks fine in ALL Browsers.
  3. Show them how it doesn't look fine at all in IE6.
  4. Make it IE6 compatible.
  5. Show them how every other browser now produces a different/unwanted result.
  6. Fix it (with heavy workarounds) so that it now looks "ok" in most of the browsers.
  7. Tell them that you will have to put this effort into ALL of your components/features and that they will have much higer production costs.

  Make sure to point out, that this would even happen if you would just compare IE6 to IE7. They may not ever switch to Safari.

Developing against IE6, IE7, IE8 and soon IE9

You should use the IE app compat VPC images for testing.

How To Distract Clients From Using IE6

I'm currently in the process of building a new site for my company and I've been looking at http://code.google.com/p/ie6-upgrade-warning/.

Essentially it's a little javascript lib that checks to see if the user is running IE6 and if so it displays a nice little overlay on top of your site. The only problem I've got with it is that it completely blocks the user from using your site. I'd like to allow for them to use it anyways but I'd like them to know that their experience may not be as good as it could be. I'm sure it can be adapted though, you should never exclude people from using your site based on their user agent. That being said I think it's a good tradeoff that you try to get your users to upgrade and if they don't wan't to they can still use your site but they probably won't see all of the fancy pancy browser tricks that you can do with modern browsers.

_{(source: googlecode.com)}

It sure looks nice anyway

Other resources include http://ie6update.com/ (not a fan though, you shouldn't trick users)

Update: Seems like someone made a bit more customizable version of this written in jQuery. See jreject.turnwheel.com

Recursion or Iteration?

It is possible that recursion will be more expensive, depending on if the recursive function is tail recursive (the last line is recursive call). Tail recursion should be recognized by the compiler and optimized to its iterative counterpart (while maintaining the concise, clear implementation you have in your code).

I would write the algorithm in the way that makes the most sense and is the clearest for the poor sucker (be it yourself or someone else) that has to maintain the code in a few months or years. If you run into performance issues, then profile your code, and then and only then look into optimizing by moving over to an iterative implementation. You may want to look into memoization and dynamic programming.

Does Ember.js support IE6?

Thankfully none of the applications I've created using Ember have required anything below IE8 support. There are still a handful of outstanding issues when it comes to IE8, which is definitely a concern for IE8 and below, but it's something I know the whole community are working on as we approach Ember 1.0.

I think the greatest downside to having to support IE6 in an Ember application are the performance issues. Whilst these will be ameliorated with each and every version, there will still be a significant lacuna between IE6 and something like Chrome 22.0. Even IE7 makes a considerable leap in performance.

Furthermore, when testing in IE8 I often get the dreaded "Unresponsive Script" dialog, and so you need to break up large JavaScript loops to post back to the browser. Failing to do so causes IE8 and below to mither you with the dialog box. Fortunately in IE9 they've made this dialog box less pedantic.

If we keep going, we'll find that jQuery announced last year that jQuery 2.0 will be the first version of jQuery to drop support for IE6, IE7, and IE8. Since Ember requires jQuery, and presumably Ember will evolve with jQuery, then long-lasting support for even IE8 might be brought into question. Whilst there are tricks, as mentioned in that document, to load older versions of jQuery depending on the IE version, Ember might also follow suit of dropping support for IE8 and below.

All in all, and with my experience with Ember and IE8, when developing with IE6 and Ember, you might come across a whole host of inexplicable quirks.

Does Ember support IE6? In parts. Is it usable? I doubt it. What is the future for IE6/IE7 and Ember? Bleak.

---

Related Topics