IE 5 has several deficiences which make it difficult to cater for when writing web applications. Two major ones are the broken box model and the broken font keyword system. IE 5.0 also lacks support for XMLHttpRequest [Update 2005-06-16: apparently it does support it; sorry about that].
IE 5.x is almost completely unsupported by Microsoft. As their lifecycle site outlines, IE 5.5 (SP2 only) is supported on Windows ME until the end of this year, and IE 5.01 is supported on Windows 2000 until 2010 – in both cases, only because it’s the version that OS shipped with. However, even Microsoft recommend in a footnote that you upgrade to get “improved security protection”. So anyone using IE 5.x is at a greater risk than they need to be.
The graph below is of browser market share, collected from the occasional press releases of OneStat, a web analytics company. There are several misleading things about this graph, due to the infrequency of samples – but let’s ignore all those and focus on the yellow and pink lines. These are the percentage market shares of IE 5.0 (yellow) and IE 5.5 (pink).
Unfortunately, OneStat stopped providing version breakdowns in November last year. Still, it can be seen that around the time Firefox was released (which may be a factor, but is certainly not the only one), the market share of IE 5 versions fell off a cliff. If that trend has continued, the market share of IE 5 now is tiny, and the market share at release time for any new web apps now under development will be miniscule.
These three factors together mean that taking time to develop new web applications with IE 5 in mind, and to test them against it, is no longer worth the investment. The resources would be better spent testing in standards-compliant browsers such as Safari and Opera – where it’s much more likely to work first time anyway.
A few intrepid souls are leading the way, and politely requiring that their customers upgrade. I invite all web developers to consider joining them.
A surprising number of Mac users still use IE5, probably because it was distributed with Mac OS X until Tiger. Of course IE5 on the Mac uses a different rendering engine with its own set of nasty CSS bugs…
You can also notice that the drop on IE 5 matches the rise of IE 6. I find it easier to believe that most users just upgraded. Maybe even with Windows Update! :)
Would you not get my money, if i choose to browse with IE5. Ha !
TheCounter.com shows IE 5 usage is still around 7%: http://www.thecounter.com/stats/2005/June/browser.php
At least it’s due to drop below Mozilla usage in the next month or two, but it may be a year or so until it’s at the level of Safari and Opera.
IE5/Win does support XMLHTTPRequest..
I’m in complete agreement with the rest though!
Yeah, still >6% with my sites. too much to neglect *sigh*
At least for our customers IE 5.x can not be neglected (>6%). We were able to drop support for IE 4 and Netscape 4 this january, and even that change started some debates.
The good thing is, that IE 5 is not as painfull to work with as many web developers are claiming. Actually all this talking about “non standard compliant browsers” bores me a lot. My impression is, that most of the “web developers” out there never tried to write a programm in C and know what it takes to make a dekstop application run on different platforms, hardware, drivers and operation system versions. Compared to that a “padding glitch” with a known workaround is a piece of cake.
I develop web applications for (old!) browsers each and every day. Create a good abstraction layer in JavaScript, learn to avoid some “known as incompatible” practices and don’t believe in any hype. Especially buzz words like AJAX (featuring XMLHttpRequest). Man, bi-directional communication has been there for years and does not need XML (especially if you only pass back a handfull values).
P.S. Opera and Safari combined have less users than IE 5 among our customers. Therefore THOSE are hardly worth the investment – but we decided to support all of them (and actually Opera is the most painfull browser to work for right now – including IE 5 – mostly due slow javascript performance and a bad debugger).
As pointed out before, IE 5.0 does support XMLHttpRequest
Yeh, let’s drop support for mac users, because that small percentage of users doesn’t need to use the web, and while your at it forget about konqueror or anything on linux. Viva la Microsoft!!!
The reason people are droping support for IE 5 is that users don’t really have much of an excuse not to upgrade – there are fine browsers that are available for free, if your still using a 7 year old app, you shouldn’t expect compatibility. Also IE 5 has one hell of a DOM, and I’m not sure about you, but I don’t want to have to take all the time to work around that. It also has a good number of CSS bugs, although most of them tend to be the stock IE bugs. I don’t know haw you got that it is simper than Opera. Finally, if we want to see the web advance to a stage were standards solutions can be standard, we need to get these poor users onto a modern browser or stop supporting them.
I agree that MSIE 5 and 5.5 have to go. They are simply too old and quirky. I am responsible for the website of the Austrian data protection commission (http://www.dsk.gv.at/), and I have to make the page accessible to all and sundry (http://www.dsk.gv.at/techne.htm). As a governmental institution, we cannot shut out citizens, even if they have Windows 98 SE with MSIE 5.0. Apart from that, there are still many companies and governmental offices that run Windows 2000 with MSIE 5.5 or thereabout. These people would be good Firefox customers. The big issues in this field are deployment on hundreds of workstations, access to ActiveX web applications and training.
Note that I’m suggesting people don’t support IE 5 in new web applications they are developing, not that they drop support for it in existing ones.
As i wrote, we decided to support most of the browsers available today and yes, we are running tests on Windows, MacOSX and Linux each day. We have a few key customers demanding it and that way it pays back.
The (sad) fact is, that for many developers supporting other platforms and browsers is hardly worth it from a pure return of investment point of view. For a small company there are not so many financial reasons to double or triple development/research time to support 5% more of the market. By supporting IE on Windows you can easily reach >85%, add Gecko and reach >95%. Why support the rest? Again, just from a financial point of view – not talking about “making the world a better place”, “not supporting a monopoly” or “making a great product” (great != financial successfull).
“For a small company there are not so many financial reasons to double or triple development/research time to support 5% more of the market.”
I recently spent a total of one hour fixing a web site that worked only in IE for Windows so that it would work on Mozilla, Opera, and Safari. It was well worth it, even though the company is run part time by one person. It’s hardly double or triple the effort to make web sites that work in nearly all browsers than it is to support only one browser on one OS.
When I write web pages and web apps, I find I don’t spend any more time making them work in all browsers. When my pages validate and give no JavaScript errors or warnings, they just work everywhere automatically.
@steve chapel
I agree, the work needed to port an application to another browser/platform is depending on the application itself. My company does streaming media and getting all the different player plugins/activex controls to work in all browsers and try to script them is a lot of work – especially to figure out all the tiny specific bugs only appearing on special combinations.
When it comes to “intranet apps” porting something like “drag and drop”, “file upload / webdav” or everything related to the activex filesystem object is a lot of work. Sure, XPCOM offers a lot of interfaces but ever tried to really port a huge VBScript app? VBScript with full rights can be hell unsecure, but being able to start and remotely control an office application with a few lines of code is something really hard to do in XPCOM.
WebApps are more (at least from my point of view) than just DHTML. You mostly also need something to access the client system – and thats only possible using features that are proprietary in each browser (well, maybe beside java applets – but that’s another story *g*).
The end of IE 5
I’ve given up on IE 4 and Netscape 4 a while ago. Meaning I won’t do anything extra for them anymore. They’ll just have to take the page as-is, no unnecessary or fatal script errors though, but that’s where it ends. If it doesn…
“The (sad) fact is, that for many developers supporting other platforms and browsers is hardly worth it from a pure return of investment point of view. For a small company there are not so many financial reasons to double or triple development/research time to support 5% more of the market.”
That is only one side of the die. The best approach is not to code to browsers but to code to standards, then fix it for browsers. (E.g. Friendster has a main css file and then a fixie.css which includes things like applying display:inline to floats and other silly inconsistencies.) Why? Because the purpose of coding to standards is not for the past, nor the present, but for the future. Basically, if you code to IE6, IE7 might break a bunch of your hacks, rendering your page an incoherent mess. If you used a fixie.css file, all you’d have to do is peruse one file to clean up your site. And on a more extreme level, two, three, or five years down the line most web sites will still be around, but browsers may change radically. We may be browsing not only with desktops and cell phones but with refrigerators and watches and god knows what else, and chances are good that these new forms of browsing will use things like CSS media-specific styles and good (X)HTML structure to break down pages. And basically, if you’ve coded to standards, you’re guaranteed (as much as possible) that future devices will be able to view your pages without major refactoring of your site.
So as Steve pointed out, once you understand the browsers, the time investment gets smaller and smaller. The return of investment for your company is that down the line (even a year or so), your website will be more robust and you won’t be spending that extra development time you speak of rewriting your site for compliance with IE7, FF2, etc.