[ars]

There is not supporting IE, and there is blocking IE.

You are blocking IE - I know because I changed my user agent on my firefox browser and you blocked me, and that is not cool!

You don't even offer an option to let me try anyway!

Use feature detection if you must, ignore IE completely in testing if you wish, but do not actively block it or you are just as bad as those who only support IE.

[nardi]

Completely disagree. There are two very major problems with this idea:

1. Your reputation suffers when users encounter issues while using the browser that you don't support.

2. The support cost of "letting users try anyway" is non-zero, and probably significant.

[maggit]

As a counterexample, let's consider Google's blocking of Opera. Google routinely blocks Opera when rolling out new stuff. I kind of get it, because of your point 1.

However, they sometimes offer a "try anyway"-link and sometimes not. The times that I can not easily "try anyway" makes me dislike Google much more than the times that I "try anyway" and it ends up broken in funky ways.

Bottom line; Yes, your reputation suffers when users encounter issues. Your reputation also suffers when users encounter the big blocking issue of not being welcome at all.

[scott_w]

I think there are some differences here:

Google are trying to keep existing users happy with the "try anyway" link. This is a new business, and they have decided they don't want to support IE.

At worst, this annoys die-hard IE users, but they're not your customers anyway.

The danger of adding a try anyway link is that people will click it, then still call and complain that your site doesn't work even if you place a huge disclaimer telling them IE is unsupported.

Finally, your website may do things that not only break in IE, but can cause your users to lose data when it does break. Yes, standard backups, never deleting data rules apply. But there is time spent either recovering, or explaining to users why you won't recover data for them.

[ticks]

One thing to bear in mind is that Opera employs "web openers" who will lobby and actively help Google to support the browser (so that "try me" link may not be as superficial as it looks). That said, blocking IE is silly.

[LocalPCGuy]

How the blank would any front-end decisions result in the loss of data if the developer was any good? They may lose the data on the form they are entering if they encounter a crash, but I think the fears of IE are VASTLY overblown. I can understand locking out older versions, but it's been pretty well established that IE9 at least, can hang with it's counterparts.

(Don't take me for a Microsoft apologist, I still hate developing for IE7 and still have to do so daily. But the IE8+ (IE9+ if you rely on HTML5/CSS3 features as core elements) is really not that hard to work with.

[jdmichal]

Well, you can guarantee that die-hard IE users aren't your customers anyway if you don't even let them sign up.

[chris_wot]

Actually, your reputation does not actually suffer. You have been up-front with your customers from the very start. If you use Internet Explorer, then you should be blocked or else you will probably come against a bug that causes you to:

* potentially lose work

* have a product that you paid for that doesn't do everything you want it to do

* get frustrated when things don't work and nobody will fix them ("Why don't you care?")

Bottom line - if you don't want to support Internet Explorer, I'd say feel free to detect it and then block it. Preferrably not via a referer string, but via something you can't change like one of Internet Explorer's own bugs/incompatibilities. Like, for example, detecting document.all, or via something proprietary or broken in IE.

[luchs]

>detecting document.all, or via something proprietary or broken in IE

Please don't do that, it will also break support in browsers which emulate that behavior for compatibility with IE-only websites. document.all is actually also there in Opera.

[Kesty]

You still can put a big red sign with "This browser is not supported, here's why.", and let the user decide if they want to try it with IE just to see if is worth it the browser change.

[TomAnthony]

If they have already tried with all versions of IE, and they know it doesn't work, then why let people bump into the problems themselves.

They are going to fail either way - it's better to fail gracefully, no?

[nardi]

That doesn't really fix either problem, IMO.

[Kesty]

IE9 is actually not that bad, and IE 10 should hopefully be very good. As a developer my bigger problem with IE9 is that sometimes I forget to comment a console.log after testing.

Their problem is that they want to be "pixel-perfect" across all browser. I get why, but as a User I don't really care as long as everything else works. And chance are that with IE9 and IE10 it will.

I'm not a IE user, but when we stop supporting IE6 we put a big sign saying that if there were problems we won't fix them and to download a modern browser. But people still went to the site even if some divs were in crazy places because basic function they needed worked and maybe they hadn't the chance of upgrading their browser.

If one of your client is once on another computer with only IE installed and doesn't have permission to install another browser, the fact that he can't use the website at all, is that a feature ?

[d4n3]

You can use the javascript shim for console in HTML5 boilerplate to make it safe for use in IE. It even logs output to a global array, so you can inspect the console output in IE.

https://github.com/h5bp/html5-boilerplate/blob/master/js/plu...

[TazeTSchnitzel]

The only thing IE10 seems to lack that's really significant seems to be WebGL. Which means IE9 may be the last version of IE that will ever "hold back" the web.

[ludwigvan]

You may use log() instead of console.log() for that. See http://paulirish.com/2009/log-a-lightweight-wrapper-for-cons...

[brudgers]

The reputation hit for blocking on the web is more or less permanent for most companies. Sure if I'm running Opera, I'll probably switch browsers to access Google. But Paydirt ain't free, it ain't Google, and I don't think I need it very badly.

What I'll have to say about it probably won't be positive.

[chris_wot]

What you have to say about it probably won't be positive if you use Internet Explorer and it doesn't work. No loss to Paydirt! In fact, a gain - they don't have to spend any development or support time explaining why they don't support the Internet Explorer specific bug you encountered.

[brudgers]

IMO, when it comes to accounting software, the browser shouldn't make a damn bit of difference to how it works, only to how it appears.

If a choice of browsers breaks a modern accounting application, that's poor design, not a feature because an accounting app damn sure better not be relying on javascript's math capability.

[Teapot]

Obvisouly, positive inclusive action is better than negative action.

Properly detect IE without false-positives. <!--[if IE]> And inform IE-users a clear and simple explaination that IE is obsolete. And there's options for easy solutions to update to better browser. Links to the usual browser choices.

[Achshar]

I completely agree with you. But there may be some kind of security issues with IE. Some vulnerability to site's authentication system or something? not impossible, you see.

[kaolinite]

The security of the application should never rely on the client-side. If you're using Javascript or similar for authentication, you're doing it wrong.

[jaffathecake]

Not strictly true, most sites rely on the client's cross-domain policy for security. Without it, this site would be able to read your Gmail & facebook pages. If a useragent came out that had a major x-domain hole, I'd expect data-sensitive sites to block it.

Not that IE fails in this way (and blocking IE in this case it wrong).

[kaolinite]

+1. Valid point but this is a bit different to what I was referring to and is an insecurity in the browser rather than the application. Still, fair point. I was mainly referring to people validating input only on the client-side, redirecting people away from private parts of the site using JS or meta redirect (last year I had to maintain a site that used this), etc.

[muyuu]

The user might get the wrong impression that he's being supported when he's not, and go ahead and buy some service that's not going to get support.

At least a big warning is justified.