Hacker News new | comments | show | ask | jobs | submit login
We don't support Internet Explorer, and we're calling that a feature (paydirtapp.com)
172 points by doctororange 1719 days ago | hide | past | web | 157 comments | favorite

Aw man. As a bootstrapping web business guy, I can say I've had way more problems with supporting iPads and iPhones than IE. IE costs me $0 to support, and I don't even bother (nobody asks!). Supporting hip and popular Apple browsers can run me a grand in a fast minute. Pleasing early adopters without working really well on the iPad3 is a tough sell.

I think startups fighting to support < IE9 is a done decision (don't do it). Start worrying about mobile and tablet platforms instead. 'cause the future, it's knocking.

I'm not crazy about getting an iPad myself, but I'm starting to feel cornered into spending hundreds of $$ on one just to keep those early adopters happy. I think this is where the real browser/device compatibility discussion is, not around IE.

We're in a similar position, except that we did recently drop the money for a new iPad. FWIW, it's actually a nice piece of kit, as long as you don't mind playing by Apple's rules of course.

However, the browser idiosyncracies drive me nuts, and we spent considerable time not just updating all our graphics but also redoing way too many different parts of our HTML, CSS and JavaScript in order to get the high-res images to display properly and to have the correct version of each image download efficiently on both Retina and lower resolution displays.

Not all of this is Apple's fault. Some of it comes from limitations in the current HTML and CSS specs, which would apply to high-res displays on Android devices as well. But some of it seems to be entirely due to choices in how iOS Safari does things, and the problems aren't limited to high-res images.

I'm still not entirely happy with many of the solutions we are using. I think we have a practical workaround for most of the issues, but often the results behind the scenes are just nasty and hacky. And as you say, it has been vastly more work than supporting IE9, which required approximately zero extra effort.

Is there something intrinsic to the WebKit versions on iOS products, or are your problems more general, i.e. learning how to support "limited" devices again (relatively small CPU, GPU, memory)?

What is it about the iPad 1 & 2 that is giving you so many more problems compared to the iPad 3?

I found I was spending way more time on IE bugs with Web app I recently did (~1000 users/month) than any other browser by far.

Hover states are a big one. Also making call-to-action targets bigger for the less precise pointing device (ie, your users' fat fingers). Making sure you use Flash fall-forwards with HTML5 video/audio available for iPad / non-flash devices.

iPads and iPhones also have great support for CSS3 transforms (3D included with hardware acceleration), but some of the other "common" CSS3 and HTML5 technologies do bog down on the slower processor. Your average desktop may not have a dedicated video card and a browser with hardware acceleration, which creates a smaller intersection of features that will work with no brains on iPads and (generic) desktops.

The list, of course, goes on, and it will continue to grow with time. As with the well known deficiencies of IE (floating, clearing, zindex bugs, etc) however, the iPad caveats and corner cases are becoming more of a known quantity. As with IE, just takes a bit more planning.

> Making sure you use Flash fall-forwards with HTML5 video/audio available for iPad / non-flash devices.

Can't you for the love of all that is binary do it the other way around? I hate it when sites push Flash on me on the desktop when there's a pure html version ready a user agent string away.

Desktop browser support for h.264 video via HTML5 is a crap shoot. Sometimes it works well (Safari), sometimes it works poorly (Chrome), and sometimes it doesn't work at all (Firefox and IE9-).

I think he's just asking for a flash fall-back if native playback through HTML5 isn't supported. Maybe that is what "fall-forwards" already meant, but I'm not too familiar with that term...

There are definitely oddities about how iOS Safari does things. Handling orientation changes and using high-resolution images for the devices with Retina displays are repeat offenders.

Well, adding support for Retina displays is definitely an iOS-specific thing (at least right now).

But orientation changes? Is that not a general "mobile issue" for you? Or is (are) the WebKit build(s) in iOS doing something specifically bad compared to (say) Android?

If you rotate an iPad from portrait to landscape, for example, then the default behaviour in Safari is to show the same page layout as you had before, but scale it up to the new width. That's far from ideal if your site uses a responsive design that could adapt quite happily to use the extra width in a landscape orientation.

Can I just mention that at least on my phone, websites that "adapt" to landscape mode often bug the hell out of me. With my getting-old-eyesight, I often rotate to landscape mode to get bigger text so I can read it more easily. When a website goes "Oh look, more horizontal pixels, I'll shrink the middle column and add some nav on the left and ads on the right!"; I'll usually just hit [back] and move on to some other site.

(Possibly interesting idea: add some analytics so that you can detect portrait/landscape orientation changes, and report on bounce rates immediately afterwards…)

In our defence, we do our best to keep the standard zoom gesture working and we use a reasonable default font size. We're not 21 any more either. ;-)

However, for most of our users, a zoomed single-column layout is going to be less useful than switching to two columns when in landscape mode on an iPad.

On an iPhone, you should see a single-column layout in either orientation using the design we're currently testing.

Can't you disable zooming to solve that problem?

I suggest you ask your 40+ year old users (or any users with less than 20/20 vision) about what they think of you disabling zooming on them…

Yes, but that workaround has accessibility problems of its own.

Well, adding support for Retina displays is definitely an iOS-specific thing (at least right now).

Not "right now". As long as you intend to support "retina displays", it will always be an Apple-specific thing.

If you want to support something as general as high-DPI devices, you know, something concrete and not an Apple marketing-term, there are certainly lots of those being made and sold as we speak. They run Android and are not made by Apple.

You might want to consider supporting those as well.

I downvoted you because your post seemed unnecessarily pedantic and condescending to me. I think it was pretty clear that GP was casually (or accidentally) using "retina display" as a generic term for "high DPI display".

Fair enough and I guess you are free to do that.

Still: targetting "retine display devices" is wrong for a multitude of reasons. You don't want your website to be tailored for a device which has 4x the number of pixels of another very specific device made by one vendor only. That is not the problem you are trying to solve.

The problem you are trying to solve is creating a DPI-independent site layout which exploits the resolution and estate available, while degrading gracefully on lower class devices.

If your solution to that problem is making your website hardcoded to fit two devices made by one vendor, as long as they remain true to leaving everything pixel perfect as they are now, for all eternity, needless to say, it's not a good nor elegant solution.

It's the "This website was made for MSIE" of olden days all over again, only this time for Apple-devices. And thats just not going to cut it.

Well as long as they are running WebKit and support the device pixel ratio media query, they will be supported.

But I'm guessing that Android phones with high-dpi screens that support that query are still at the single digit percentage of browser statistics.

That's fine for CSS images (media queries), but what about content images?

All the code I've seen for content images involves some JavaScript stuff that uses the device pixel ratio as well.

The server should not have to decide which image to send, based on whatever it can gather of a combination of various factors, including device display resolution capability (double-density vs regular pixel mapping) and connection quality (wireless vs broadband) or whatever else comes into play. The server should be advertising the capability of high res images and the user agent should be requesting them if it wants.

That's a great idea, but that's not currently how it works. All of the high-res website image stuff that I've seen all uses client-side JavaScript to fetch the 2x images.

Yeah, that's just a broken way to go about it. We need to put pressure on browser maintainers to fix it. I feel dirty doing a hack like that.

In my experience, the problem is that the Android/WP7/[other smartphone OS here] web browsers are so far behind iOS WebKit in terms of functionality that you basically have to handle each device on a case-by-case basis. Given that, a lot of developers choose to focus solely on iOS since it's the lowest-hanging fruit with a massively large userbase and a relatively-standards-compliant codebase.

For example, all mobile web browsers should theoretically throw either a resize or orientationchange event on orientation change, but some Android devices don't, with no other viable fallback, and no clear rhyme or reason as to which devices support it and which don't (other than that newer flagship devices are slightly more likely to be standards-compliant). CSS media queries are more consistently supported, but they aren't the solution to every problem.

What percentage of your users were on IE?

I think around 70-80%; the product the Web app was supporting was targeting schools/non-profits and other demographics where IE usage is high.

So isn't it fairly natural that IE would account for most of the bugs (if that represents 3/4 of your users)?

"Early adopters" - surely we're beyond calling IPad owners early adopters? As for desktop and tablet support, is it really that hard with excellent toolsets such as Bootstrap etc. ?

iPad _3_ owners are 'early adopters' to me - and I understand the gp as having trouble supporting the latest and greatest features - or changes- in those things.

Like the retina display, which does seem to require some dev love to look decent, according to statements on this very site.

Sure, they're early to you, but not to the consumers or industry. The adoption cycle applies to a product family, not model. The iPad is not a new device.

This is where things like 320 and up: https://github.com/malarkey/320andup and future GUI libraries (Twitter bootstrap as a single example), will start to change everything.

The main problem with what you've mentioned is the size issue. So for startups that are dire in need of building fast and getting things right but not looking stunningly beautiful - this is an option.

The people with too much money to know what to do with it, can then build things in a crazy way with agencies for the logo, different agency for web design and then a 3rd agency for build etc.

I'm confused why you believe you need hardware for testing? iOS simulator should be plenty sufficient in any standard dev environment...

As an almost universal rule of thumb, there is no perfect simulator/emulator substitute for a target hardware platform.

For example, the iOS Simulator runs in an x86 environment. There's no way to throttle it to run at hardware spec speeds, never mind that the Safari in Simulator is quite possibly running different code than the Safari that ships on the devices themselves.

Buying a mac to run the simulator on is much more expensive than buying an ipad.

You can get a refurbished Mac Mini for around the same cost as a new iPad.

And buying multiple versions of the iPad is also more expensive than a mac to run the simulator?

I had never heard of the iOS simulator! Thanks for mentioning it, it just changed my friggin life. I'm on Snow Leopard, and there is no free upgrade to Xcode 4.0. I hunted down a torrent of 4.2 and got it installed though, and the simulator is pretty great.

My larger point is that the hassle isn't supporting X version of a browser anymore, it's supporting X version of a browser on various hardware devices. Web-dev hell isn't going to be the fault of IE anymore, it's going to be the fault of mobile platforms with differing browsers, screen-sizes, and use patterns.

So you don't need iOS hardware, just Apple hardware... so much better!

People without Apple hardware create websites?

So very amused by this!

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.

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.

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.

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.

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.

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.

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

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.

>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.

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.

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?

That doesn't really fix either problem, IMO.

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 ?

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.


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.

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

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.

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.

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.

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.

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.

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.

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).

+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.

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.

>"In reality we've received exactly zero requests for IE support, angry or otherwise."

Why would someone bother contacting you when it appears that your site is broken? In other words, the call to action doesn't display technical competence - indeed it implies a level of technical incompetence which probably is not justified.

"We're really sorry, but Paydirt isn't playing nice with your browser" doesn't inspire confidence in the product - it doesn't suggest a high level of customer service, either. Would I really want to trust something as critical as invoicing to this company?

Furthermore, not supporting IE doesn't scale well. At 10,000 users 1.6% is $1600 a month in revenue. At 100,000 it's nearly $200,000 a year in potential revenue - all for what is mostly a one time expense.

Finally, where does this leave room for expanding services such as letting my customer's see their project in real time?

I don't see a business case for it. I'm not saying that there isn't one - just that it hasn't be made.

1.6% is 1.6% no matter how big the number is...

Personally, if my app were making 12 MILLION DOLLARS a year I'd either a) not care about that $200k a year or b) I'd then have the resources to do something about it

If I were these guys I'd support Spanish and French long before I'd bother chasing that 1.6%, but no one is being critical of them not doing that.

Exactly. There are many ways to alienate potential users (missing languages, missing features, etc). In the early stages we've learned the importance of focussing on the biggest bottlenecks first.

If it is 1.6% of people clicking the call to action, then something meaningful may be concluded. If it is total traffic on the site (my understanding), it is a less meaningful number because the non-customer IE visits are being measured against recurring customer visits, i.e. first time visits are being compared to heavy users.

That's good point. Taken on board, and we'll improve the page to encourage IE users to let us know. It's very true that things might change which would require us to change our tack, but as a bootstrapped startup with a hundred things requiring attention, IE support has taken a back seat.

Putting a standard front end task in the back seat raises the question "what other corners were cut?" particularly on the backend.

If you are selling a game, I get it. It makes sense.

But this is B2B sales and you're asking me to trust you with client information and my sales data.

Just because I'm looking to replace Quicken or Quickbooks, doesn't mean I hate Microsoft, nor does it mean that I want my mom to jump through hoops every Thursday when she does my invoicing.

Not supporting IE9 (and probably 8) falsely segments your potential market.

You must also understand the costs of supporting IE, I think is bigger than the revenue of those 1.6%

Depends on if you believe that 1.6% figure is an accurate representation of how much business they are losing out on by not supporting IE. I would wager that number is generated from bad data specifically caused by their decision not to support IE.

Depends on the revenue obviously.

You may have mis-interpreted the fact that because 1.6% of your users have IE, that means that you're in a space where those customers won't use IE.

What it may mean is that you don't have very many customers. If you were mainstream, you'd have more IE users... just like the rest of the Internet.

It's okay not to be mainstream... but, if time tracking is a competitive and profitable space, your competitors may be happy to share this blog post with their prospective users.

I think it's more critical than just having less IE users in that space... The thing is, 1.6% of total traffic does not equal 1.6% browser usage.

If all your IE visitors are seeing is a landing page and a message saying "sorry, we're too lazy to support for your browser", then of course they'll turn around and never come back. If they were to let IE users through, that number would most likely jump up - significantly.

I know a couple of hardcore IT guys and programmers that are really happy with IE9, and hate Firefox and Chrome with a passion. It happens!

> I've spent literally hundreds of hours trying to get sites to render pixel-perfect across various versions of various browsers

Why? This is a sub-optimal approach. The same machine with the same OS and the same version of the same browser can render very different looks just because they user has different settings.

How do you know that your user even has a visual display? Does it matter to you if they have a portrait or landscape display?

> future versions of IE will probably be standards compliant

Are you saying that all your code is standards compliant and you're not using any browser-specific extensions?

I can answer second one. 60 counts for -webkit, 58 counts for -moz, 17 counts for -khtml.

One thing I hate is websites that block me from trying to use a site based on my browser. Give me a stern warning and let me use at my own risk. I'm not defending IE this has happened just as much in firefox and chrome for me.

I applied for a job recently that wanted me to take a test that required IE and windows. I passed on the job because that test was a fail.

The web, like anything, has costs and benefits. A big benefit is that you and develop and deploy an app once, centrally, and anyone can access it from anywhere, on any sort of web device. The cost of that is that you can't control how they're accessing it. To have the benefit, you have to accept the cost.

By shirking the cost of providing even some level of support for IE, you're ditching the benefits afforded to the part-time copywriter who needs to stay at her desk and work her lunch hour during the office job she keeps to make ends meet. You're ditching the benefits afforded to the business owner on the road whose laptop won't join the hotel wifi and has to use the hotel's "business center" to issue the invoice needed to meet his mortgage payment. You're ditching the benefit of a happy customer evangelising the product to a colleague, and wanting to give them a quick demo by logging in on whichever laptop is currently hooked up to the meeting-room projector.

The times when a user doesn't have control over their environment are the times when they need a product to come through for them the most. Especially when that product is their means of getting paid.

Not being able to offer "amazing things with canvas" to IE (or any browser) is okay. Not offering support to be able to log in and perform a set of basic key tasks from any browser whatsoever is, to my mind, throwing away one of the biggest benefits the web can offer as a platform.

I target a similar audience (freelancers). If anything, a feature would be supporting IE, especially when your app does a lot with CSS3 and bleeding edge HTML5 stuff.

And features need to be justified. Planscope (http://planscope.io) gets less than 2% of all traffic from IE (chart: http://dl.dropbox.com/u/2205912/iestats.png), and for actual accounts there's only been one person with IE - and that was a client that one of my customers invited in. 5 minutes later, Chrome Frame was added and everyone was happy.

I've also recently built a social network for amateur gardeners. The average age was probably 50. Did I ensure IE was fully supported? You bet.

Good feedback. Thanks bdunn.

My personal web projects always start with standard-conforming HTML with forms and links. They're fully interoperable contributions to the world-wide web and should be usable by every browser and robot written in the last sixteen years. I call that a feature, and I'm disappointed that so many devs set their sights lower.

That's nice. The problem is that Internet Explorer doesn't conform to these standards. What do you do in this situation?

IE has a nasty habit of sniffing content or examining URLs and disregarding the actual media type of a resource, but it hasn't come up much in practice, and otherwise I haven't seen any showstopping problems in talking HTTP and rendering semantic HTML. Its CSS and javascript are a mess, but those are optional, and I'd be embarrassed to release anything that would become completely unusable without them.

Ignoring almost 30% of the internet and calling it a "feature" doesn't make it the right thing to do, or the smartest thing to do.

As you grow and (hopefully) become more successful you may start running into friction from IE users who want to use your service but can't.

Once you've saturated the market of other browser users, how will you continue to grow?

When you get there I think you might regret not investing in IE support today.

What about your application is SO compelling and SO difficult to support in IE that you can afford to ignore that entire market segment?

I didn't support IE until, much to my chagrin, I discovered about 30% of my hits were from IE. Fortunately, simply putting the !doctype meta-tag (or whatever it is) fixed almost all my issues (at least for IE 8+)

Very wise. This post is by no means a prescription for everybody. We're lucky that our demographic tend to use stronger browsers. Actually, when I exclude blog traffic the IE percentage drops further. :)

If you are spending a lot of time fixing html/css issues in IE6, 7 or 8 it maybe due to over using floats and clears. Especially for elements inside a container block which are spread apart from each other like elements in a header block (<div id="header"></div> or <header></header> if HTML5).

For the header block where you have elements spread apart from each other the better solution is to add position: relative in the div id="header" and then absolute position the elements within the header (i.e. div id="logo" and on the ul for the navigation; float the li(s) though).

Using floats, margins and clears to position the MAJORITY of your elements will prove to be frustrating once you test in IE (6,7 & sometimes 8).

This is interesting because I use a pseudo-grid system with plenty of floats and clears. For some reason (research), it seems to look perfectly fine in IE 6+ and Quirks Mode.

> We don't spend hours debugging obscure IE bugs

IE "bugs" are rarely obscure. Most "bugs" are actually as-intended behavior, which is documented on MSDN. Do your homework.

> Sensible browsers can do amazing things (canvas, SVG animations, CSS3, web-sockets, blazingly fast JS), and limiting usage to these lets Paydirt take full advantage of these new technologies.

As was mentioned earlier, graceful degradation renders this point moot. Web pages do not need to look and function the same in every browser.

> Originally, we feared that we'd receive a torrent of angry emails from avid IE users. In reality we've received exactly zero requests for IE support, angry or otherwise.

Ignorance begets ignorance. The lion's share of people that use IE aren't technically savvy. They're people like parents, uncles or even grandparents. Why expect them to know how to send complaints when they barely know how to use a web browser?

> We work harder when we're happier, and skipping the dirty work of IE makes us very happy.

Clearly you were never working hard to begin with. Supporting IE is much easier than Internet FUD makes it appear.

> Who knows – future versions of IE will probably be standards compliant, super fast and reasonably secure.

You mean like IE 9? A little-known fact is that IE 4-6 were the most innovative browsers of their time. `innerHTML`? IE; event listeners (`*tachEvent`)? IE; editable text content (`innerText`)? IE. Those are some pretty important additions from a platform that seems to get no respect.

Cut the browser elitism and get a clue.

I don't read articles espousing insular design practices, and I'm calling that a feature.

Your blog doesn't support comments. Is that a feature too?

As a developer I sympathise, but as a user I don't. I can understand not supporting IE 6 and 7, but not supporting 8 and 9 is not a feature, it's a lack of feature. It's saying that you aren't prepared to work with me the way I want to work.

It may be the right choice, but don't sell as that it's not.

IE market share has been going down for years, but it's still more or less 70%

That means that by not supporting IE you don't get 70% of the market. Early adopters come and go, but "hockey stick" growth like the one Pinterest got? that comes from the mainstream market that uses IE and doesn't knows what Firefox is, and thinks that by Chrome you mean actual chrome...

But as I said IE is going down, and when it hits 50% in 2 years or less that will be the time to stop supporting IE.

70%? This looks like worst case scenario to me. Here we have IE hovering about 25%: http://www.ranking.lt/en/rankings/web-browsers-groups.html

Over THERE, also Chrome is the leading browser in Latin America, but how big are those markets?

That doesn't seem to be an issue for them. From the article:

> Originally, we feared that we'd receive a torrent of angry emails from avid IE users. In reality we've received exactly zero requests for IE support,

More generally, the "market share" depends very much on what you consider to be "the market". If your target audience are big companies stuck into MS support contracts then yes, IE market share is huge. If your target audience are mostly individuals with some basic knowledge on computers, they are almost certainly already using a sensible browser.

Ever seen the average user for Pinterest's? do you picture a +40-yr old woman mailing some devs because the page she's looking at didn't load? They don't bother, just leave and never come back, simple as that.

Just like IE users don't bother to find out which browser is the best they don't bother to email some unknown no-name startup they stumbled upon because the page didn't load.

And again I'm talking about a different and much bigger market than early adopters.

I never saw any app or website that would have a that low percentage of IE usage.

Anyway, if you have been working with html&css for more than 1 or 2 years it should not be hard to at least degrade gracefully on ie8+.

Personally I don't even think it is a choice, ie is still 30% of world average, supporting it is a must.

It really depends on the site though. I get almost zero IE traffic.

Graceful Degradation - look it up.

The baseline compatibility should be "functional but not necessarily beautiful".

Not wasting time getting pixel-perfection in IE is wise. Blocking IE is retarded.

The fact that you haven't even considered using Chrome Frame says a lot about your dev skills. Or, you know, lack of.

Ten years ago you were an elite web developer if your site worked well in browsers other than IE. Today you're an elite web developer if you can make your site work well even in IE.

Getting the vast majority of sites working in IE9 is trivial (no changes required). IE8 some changes, but not a major hassle. I don't support IE7 or before. If you use a lot of HTML5 features it is hit or miss on all browsers.

You're right. My recent encounters with IE9 have been pleasantly surprising (and I bet IE10 will be quite competitive), but for us the numbers are so low that, at least for now, a broad sweep feels OK.

Guess I'll never be an elite web developer with that definition. I'm too busy actually using web features instead of depressingly fighting IE bugs.

That's a valid choice, assuming your userbase is similar to the one in this article.

Apparently, they don't really know what they're doing...

    function cj() {
        try {
            return new a.ActiveXObject("Microsoft.XMLHTTP")
        } catch (b) {
I guess this JS code is not for IE support...

This widely depends on your geographics.

Writing from Brazil here : still over 70% of the visitors, on average, to most sites I monitor are using some version of IE.

So claiming a "feature" like that down here would be like rejecting 70% customers on a popular mall because they're not wearing red shoes(or some other arbitrary reason).

Except it's not arbitrary. Each browser they support adds development costs and takes time from their devs.

It is more like choosing not to serve vegan options at a dinner. Sure, it might piss people off but they could always suck it up and just eat the bacon.

They are not selling the product in Brazil.

They are on the World Wide Web. If they aren't intending a world wide customer-base, they are missing one of the major features of the web.

I don't really understand why this is newsworthy. If I made a website that had almost exclusively IE usage and chose to only support IE, would that be a feature? No, it'd just be an appropriate use of my development resources.

I support whatever my client needs. They pay, I code. End of story.

I believe HN had a story linked a few months ago where supporting IE was specified as a separate line item in the budget, forcing their clients to really contemplate the costs (in both time & money) supporting such a broken browser family. If that's what you mean, then kudos, as I think it's a great learning moment for clients.

Yes, I do mean that. I will support modern browsers, but legacy stuff is additional (though not that much really).

I consider anything older than IE8 to be legacy.

On the other hand, if I put out a product that is aimed at the enterprise market then I will support older stuff. Enterprise moves at a different pace.

Story time: I once found myself working in the banking industry only to discover they used .NET 2.0. This on 2011. They also had a bunch of Win2000 machines. My job was to make a system that ran on all.

Pulled it off, but it opened my eyes to how big business works.

Absolutely. We do dev work on the side, and in those cases take our orders on browser support.

I get annoyed when people are too lazy/incompetent to support IE6, but blocking IE altogether is beyond stupid.

Don't get me wrong, I see the benefits and if dropping it makes sense (hint: it doesn't make sense when you quote average IE6 figures, check your own analytics and justify losing that many users), but quite frankly if you can't handle IE9 then I have no confidence in your product.

> I get annoyed when people are too lazy/incompetent to support IE6

That's kind of a strange sentiment, especially considering IE6 is basically extinct in the wild (unless you are targeting users of pirated copies of Windows in China)...

Also, I think many people these days have better things to do with their lives than f--k around hacking in circles in CSS to get things working for IE6...

> That's kind of a strange sentiment, especially considering IE6 is basically extinct in the wild (unless you are targeting users of pirated copies of Windows in China)...

Incorrect, at least in the UK. If you believe the general stats that are pushed (hint: don't) then that would be the case, but we test on a client-by-client basis for many large sites and there are still a decent number of people using IE6, enough to justify a few thousand on making a site IE6-capable.

> Also, I think many people these days have better things to do with their lives than f--k around hacking in circles in CSS to get things working for IE6...

I can't wait for IE6 to die, but for most of our clients 2% of users would easily pay off any cost for us to handle IE6. For now, we follow the Yahoo baseline (http://yuilibrary.com/yui/docs/tutorials/gbs/) at minimum and make sure that our sites work in IE6.

I don't want to be a dick, but PayDirt isn't all that complex. Don't see what the big deal is here. Even if 1.63% of their traffic is IE... It's still 1.63% of potential customers you're theorectically dismissing. I also find it rather shocking that your IE traffic is so low. Are we talking about requests or unique visitors? What group are you advertising at?

I agree with not supporting IE, but calling it a feature is just a rationalization on not providing support for it, and a nice spin at it.

True, it's really just a spin. It's a benefit for most of our users because we can use the time more productively to improve the product and support in other ways. In the zero sum game of the 24 hour day, an hour saved is an hour earned.

There is a lot of danger in defining yourself in terms of what you DON'T do.

For example, I don't know what your company DOES do, but I know you have devoted time and energy to taking a pissing-match stance against a browser.

This is not new, for many years there are many sites that block IE or serve IE users special pages that say "let me help you get a better browser in a highly-condescending, smug, and self-righteous way". You are not inventing anything by putting in this browser blocking.

Anyway, not my problem really.

There could be somewhat of a chicken-and-egg thing happening here with their low IE take-up. On IE 9 the slideshow on the home-page doesn't work, it just says "... loading fancy-pants slideshow ...". If I came across that as an IE user, I wouldn't be signing up.

There is also the demographic for their product, which is the more-likely reason for low IE rates. I wouldn't be surprised if the big Mac-OS screen shot on the home page turns off Windows users as well.

In fact, they don't want you to sign up if you are an IE user. You can't even.

It's real simple, medium and large enterprises are on IE 7 and 8. Technical end users are on Chrome and FF 80% of the time, the rest is a mix but it's less than 10% IE 8 and below. This application is not targeting enterprises, it's not a big deal.

We have a product that is enterprise only, if we didn't support IE 7 or 8, we'd have no business left. This is a few years out of date to be news, the guy's done well to get his free advertising.

Can someone with a windows machine proxy this into IE and see if anything is broken? I can't believe there is much overhead in making things look fine in IE(>=9). Especially a straight-forward site such as theirs.

I haven't heard of paydirtapp before, but now I'm stuck with the impression that they are silly. Trying (and succeeding) to get publicity by being silly.

I should make a post about banning users on iOS 3.x, or perhaps all Opera users?

"trying to get sites to render pixel-perfect across various versions of various browsers" - That is a big part of the problem. Now, I have designs I have to get pixel-perfect, so I feel their pain, but when developing your own app, you can opt to not go for pixel-perfection.

I don't believe their statistics, but their target market is much more likely to have multiple browsers and is probably willing to jump into a different browser if IE isn't supported.

But I think it is a dumb move to block IE9+. There is no good reason for it. They didn't give one in their blog post, and I have yet to run into a situation where if I am using web standards that I had many issues with IE9. Nothing I've had to hack around enough that I would want to block it. Seems like either an anti-Microsoft for the sake of being anti-Microsoft or just front-end devs not worth their salt (cause a front-end dev worth their salt wouldn't use user-agent detection to block IE in the first place, they'd use feature detection at least.)

Users don't understand. Browsers are browsers, and for a vast majority of users, IE came with their machine. You aren't going to provoke thought, you'll just lose potential users.

I can understand not supporting legacy IE. Not supporting modern IE doesn't make sense. It seems a lot like nerd rage misdirected.

Another company I won't be dealing with...

Can someone at MSFT comment? How is the IE team composed? Is it a threat at MSFT, to be placed on the IE team? "If you don't start performing, we're sending you to work on IE"?

I for one would love to work on the IE team.

Actually, I think people aren't considering the fact that some of the people using IE will download a supported browser.


I wish more sites would nudge users to upgrade to a "modern" browser, including IE9. Microsoft is silently pushing IE10 to most IE9 users, so within a year only around 10% of users will be on a non-HTML5 browser. Assuming IE10 or latest Chrome and Firefox will be a giant step.

Sadly a lot of folks are still stuck with Internet explorer. I still make it to a point to make my web app work at least in IE8 and above and make it seamless as possible.

What I would do is that I'd give users with old browsers a plain version of the site. E.g. No transitions, animations, etc.

Supporting Internet explorer is a pain in the back, but a good developer and designer will do his best to provide availability. That's what I learned so far in the past 6 months.

Interesting - I wonder how folks would have responded in the 1990s if someone had stated "We don't support Macs, and we're calling that a feature."

I'm unclear as to how this is even remotely relevant. Mac compatibility has been a pain in the ass for.. err...... who again?

IE compatibility has been a pain in the ass for pretty much every web developer everywhere up until very recently.

I'm thinking desktop apps - most companies would create PC-only versions of software in the 1990s -- or PC-first.

Regardless of paydirt's decision, IE's tw0-year release cycle isn't doing any help to stem this sort of perception. IE10 will be awesome, but it has to ship and MSFT has to transition all users of IE6-9 onto IE10 or another browser that will stay current. If users stay abandoned in IE8, the greatness of IE10 doesn't count for much.

Hmm -- never heard of them -- neither has Quantcast or Compete. Alexa knows who they are -- says their users spend a whopping 86 seconds on the site.

Tweet from dbushell // David Bushell hipster apple developers @paydirtapp block IE. Every sentence in this article I reply with "You're Doing It Wrong." paydirtapp.com/blog/we-dont-s…

F o l l o w e d

Read the whole article and all these comments and I'm still waiting to hear what makes this a quote unquote feature. Making a decision is not a feature, otherwise Friday team lunch at Chipotle is also a feature.

Hey Paydirt: Your Site Works Just Fine in IE http://news.ycombinator.com/item?id=3945353

I like to stay on the horn for a few seconds when people do extra stupid things while driving... that's kinda what you're doing to people using IE. Good job

We don't support Internet Explorer, and we're calling that a feature*

*An option few have, so don't be ignorant and categorically mimic our approach.


yay! Something I did with my homepage http://adnansiddiqi.com. Try it on IE :D

Do you know that your site works OK on IE9 when changing the UA?

Ironically, your site page does not include a doctype so it is interpreted in quirksmode [1]...

[1] http://en.wikipedia.org/wiki/Quirks_mode

Yes I do.

This would have been interesting news in 2007 when ~70% of the internet was using IE and the versions that people used were hard to support. Now, it just seems like silly bragging. I can understand silently not supporting IE because of the features that aren't present, but shouting that you don't support IE in 2012 and calling it a feature just comes off as arrogant. My first reaction is, "so what?"

You seem to be missing the point. That we have come so far in the browser wars that IE can be unsupported as a valid business strategy is a pretty big deal.

Well done! I expect the contrarians to pour in screaming about not leaving anyone out and elitism and corporate users and blah blah blah... But seriously, fuck IE. if you don't have to support it then don't! More power to you! My biggest wish as a developer is for some major site to stop supporting IE. I do feel for the users but I feel it's a necessary evil to get the IE team to either ditch or fix Trident or whatever engine they use nowadays. There is no other browser that is more fragmented, unpredictable, or harder to get anything rendered correctly in than IE. if just one major site stopped supporting it then just maybe Microsoft would finally fix their broken browser. We are forced to write far too many unnecessary lines of code just to support a single browser when the rest of our front end code pretty much works effortlessly in the other browsers.

But we live in the real world and my wish isn't likely to come true. We do, after all, still have to think of the poor users who are either ignorant of the alternatives, still using IE due to inertia, or couldn't even upgrade to a version of IE that worked nicely (that is, if it existed)if they wanted to due to being stuck with their version of Windows Vista Home Office Extended Premium Plus which can't be upgraded to the new Windows 7 Midgrade Basic Premium Exclusive Edition Service Pack 10million which is the minimum version of Windows that'd run such a browser for less than the cost of sacrificing their first born child. Internet Explorer 9 was a noticeable improvement by far but not good enough still. Version 10 looks even more promising. Too bad they make it so that only the smallest fraction of Windows users can upgrade to them.

I have more trouble with Firefox than modern versions of IE.

I also have a Pentium III that's running Windows 7 and IE9 now (and will be able to upgrade to IE10), and if that can upgrade to IE9, it's utterly and completely disingenuous to claim that the "smallest fraction" of Windows users can upgrade to it. Instead of being rational, you come off as a sneering cheerleader and, y'know, that can entirely be your bag if you want to pick it up and run with it, but it'd help if you at least used your mouth for talking instead of parts down below.

Is it rational to claim that if you upgraded a Pentium III computer to Windows 7 you aren't in "the smallest fraction" of users of old computers?

The point is having a Pentium III Win 7 machine covers using a Pentium 4, Athlon XP, and all those other old computers to install IE9 - covering the biggest fraction of users through backward compatability.

Correct, thank you.

You can run Windows 7 on pretty much anything that will run Windows XP. "It costs money to upgrade" may prevent you from doing so, but at this point, after a decade, it's not Microsoft's problem if you're not willing to spend the money. They're not obligated, nor should they be obligated, to avoid using their new stuff (Direct2D, for example) in order to continue to target XP users.

To be more precise, not everything, but yes generally most Win2000-era and later hardware.

Well, I think Win7 has larger market share than Vista.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact