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. :)
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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...
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.
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.
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.
"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.
Then you're doing it wrong. I've been doing web dev for eight years and have a staff of 8 developers. We can spend up to 50% of our time getting things to work in IE. The extra time we spend fixing the few problems with anything else has NEVER been billed to our clients cause we consider that almost nothing. And I'm talking about the iPhone, iPad, Android and any browsers you care to bring up.
IE has always been the worst browser on the planet by far and will always be years behind all others in modern standards support and practices.
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.
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.
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.
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.
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 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.
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.
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.
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 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.
>"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.
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.
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.
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.
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.
Seems like it's a fashion statement more than business decision ? Unless your app is point and click, it's unlikely to get too much usage from Ipad. So in that case, will you stop supporting that too?
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!
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.
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.
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.
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.
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 ?
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 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.
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.
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.
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.
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'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?
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.
166 comments
[ 208 ms ] story [ 4111 ms ] threadAnyway, 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.
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.
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.
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?
(Possibly interesting idea: add some analytics so that you can detect portrait/landscape orientation changes, and report on bounce rates immediately afterwards…)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Like the retina display, which does seem to require some dev love to look decent, according to statements on this very site.
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.
IE has always been the worst browser on the planet by far and will always be years behind all others in modern standards support and practices.
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 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.
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.
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.
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.
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).
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.
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.
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.
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.
IE compatibility has been a pain in the ass for pretty much every web developer everywhere up until very recently.
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).
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.
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.
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.
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!
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.
At least a big warning is justified.
Not that IE fails in this way (and blocking IE in this case it wrong).
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.
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 ?
https://github.com/h5bp/html5-boilerplate/blob/master/js/plu...
They are going to fail either way - it's better to fail gracefully, no?
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.
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.
(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.
* 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.
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.
What I'll have to say about it probably won't be positive.
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.
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.
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?
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.