I came across this older blog post today and it got me to thinking about which browsers you, as a web developer at the university level, support. The author had some nice graphs in there which listed which browsers he supports and to what extent he does.
I’m writing mostly to get my own thoughts down at this moment in time. I’ve recently been hunched over my own college’s analytics to make some determinations on how our website redesign is going to commence. So, I’ll just list off some general categories and what I’m doing within those categories.
Internet Explorer
Luckily, we are dropping IE6 this time around because its usage has dropped below 1% of all total traffic. That is not the ONLY reason for dropping it because IE6 also needs some annoying hacks to get things to work, encourages me not to use modern web technologies without providing an alternative, and would increase development time. IE7 is still there, rearing its ugly head for the time being, but its share is dropping as well and I can only hope that it will disappear within the next couple of years so that we can drop that too.
IE7, IE8 and IE9 will all be supported and I’ll be testing all three. IE8 is currently the default browser on campus but I am hoping to push IE9 through as soon as it is released. I would love to drop all of the older versions, but they are going to be around for a LONG time because Windows XP will only be able to be updated to IE8. I would encourage anyone who is stuck on XP to use either Firefox or Chrome to make things much faster.
IE7/8 will not, however, receive all of the graphical “candy” that some other browsers will. This mainly is due to the lack of CSS3 support on those browsers, but everything will still be accessible and looks good.
IE9 is going to be targeted to be as compatible with all of the candy as possible just to see how far I can push things. It should be fun.
Firefox
I will be trying to aim for Firefox as one of the standards for browsers (along with Chrome). Firefox is available on Linux, Mac and Windows so that way I can provide a comparable experience on all three platforms (same with Chrome). Firefox 4 is going to be an interesting beast, if they ever launch it, and I’ll do my best to support that browser as well. Not too much to say here other than Firefox 3.5+ will work.
Chrome/Safari/Webkit
I’m lumping the three of these together even though they are not the same browser, but the first two share the same rendering engine (Webkit). Chrome is available on Linux, Mac and Windows and is the second of my standard testbeds. I actually do all of my coding with Webkit browsers in mind first and then make tweaks from there to accommodate any oddities that arise. It has worked well in the past.
I’ll also be making sure that Safari 4+ on the Mac works as needed, even thought Safari 5+ will be officially supported. Anything newer and I will probably end up pushing you to another browser (more than likely Firefox for the older machines).
Mobile
One of my goals is to provide some kind of mobile experience for iOS and Android devices. Sadly, Windows Phone 7 will probably not make the cut nor will the newer Blackberry phones. I’m not sure what I am going to do about the older Blackberry devices because there are a great many of them still in use on campus by faculty/staff/administration, but they provide such a minuscule amount of traffic to the current site.
I need to look at either providing a m.mlc-wels.edu or looking into media queries to handle different devices. This is a longer-term project, but one I am excited about.
Conclusion
Main thing is that I’m shipping with IE7+, Firefox 3.5+, Chome 5+ and Safari 4+ support for the website when it will originally ship. The pairing down of needed versions is something I will continually try and do to cut back on code needed to support different browser versions.
With the upcoming rolling-release development cycle for Firefox (which Chrome already does), I’m hoping that it will push web standards farther ahead by incorporating them when they are finished instead of waiting for the next big release so that you can have more bullet points in a press release.