Browser Support

mozilla

7 responses

Browser marketshare February 2009

For the past couple of days I’ve been pondering our browser support chart that the Mozilla webdev team wrote up about a year ago. Since then, the browser ecosphere has changed considerably. Chrome burst onto the scene with no warning, IE8 was released and Safari 4 is up-and-coming.

One of the toughest parts of being a web developer is deciding what browser to support and how much to support each one. Should it be a binary decision, either support 100% or not? Support some browsers 100% and offer limited support for others? If you decide to gracefully degrade, how much and what features/functionality are considered essential?

And how do you decide which browsers to support? Do you choose via market share, cost/benefit, current/previous release, your website’s audience?

This is an especially tough decision when part of Mozilla’s mission is to promote openness, innovation and opportunity on the Internet. Not supporting a browser simply because a small percentage of users are using it and it’s difficult to code for goes against this mission. Websites and their content should be easily accessible for all platforms, browsers and devices.

It’s a constant battle when there is a distinct need to release early and release often, yet support as many browsers as possible. The added work of supporting more than the most recent browsers is not insignificant.

In the spirit of openness, I want to hear what the community has to say. What are your thoughts for browser support? What will promote Mozilla’s mission but also allow us to develop quickly?

7 responses

  1. Simon wrote on :

    Our product is web-based, for internal use at our clients, so mostly we support IE7, and Firefox. In theory we’d run fine on anything reasonably standards-compliant (Opera, Chrome, Safari), but they’re not significant enough in our market to rate any particular effort.

  2. Jim Plush wrote on :

    It’s the battle every dev has to make and it all depends on the target audience. I worked at an ecommerce company where I had to support all the way back to netscape 4. Their contention was if they miss one order then it’s an issue(to which I argued they’d spend $10,000 extra dev dollars to get $1,000 worth of orders which they didn’t care about).

    In my current B2B app I mandated we only support IE7+ and Firefox2+ to allow for more rapid development of features. You could argue ie6 belongs there but I would label it FAIL. Management has backed that decision here so that’s lovely.

    As far as new browsers coming into the market they should be obligated to follow the standards outlined already to enable the most rich user experience with the least human development effort. Think of the lost productivity of mankind as a whole trying to support IE.

    I’m sure mozilla as a whole leans towards more technical oriented individuals which means you can raise your browser standards to more current versions, however that also means you have more techies trying out the latest greatest browsers which means you need to support more browsers in general. You could set your top 5 browsers then note that once a browser hits X percentage of saturation you add that to your test bed and once a browser falls to X percentage of saturation it is removed. That would give QA and Dev time to ramp up the automated test beds.

    For development/QA, unit testing with something like selenium RC Core which can abstract all these browsers for you means you don’t have to physically test every checkin as a developer in each browser/version which can save your sanity and abstracting your JS and CSS to frameworks and libraries can minimize the development effort as well.

  3. Montana Harkin wrote on :

    At Oregon State University we have moved to a policy of only supporting browsers which are above a threshold of 2%. Sadly this includes IE6. Due to this threshold we perform testing on IE6,7, Firefox 3 (2 is < 2% now), and Safari 3.

    In addition to the testing we perform on those browsers, we also make sure to create a syntactic web to ensure screen readers and text based browsers can still access the content. Any areas that are dynamic we will try to provide alternate means of accessing it, either by searching or an alternate index.

    For Mozilla I see some of the same needs. Support the majority of active browsers while still being accessible. I agree with Jim’s comment about utilizing Selenium as this can take much of the pain out of interface testing. In our projects the budget is not usually allocated for this level of testing, but I can see some of the larger Mozilla projects getting some return on the time to set it up.

    Right now I feel that the area which will need the most focus on standards and testing will be mobile browsers. With desktops, it is easy enough to get a user to update their browser, and when IE6 is out of the picture there will be much less complaining (knock on wood).

    Just reading PPK’s notes about mobile browsers makes me want to cry. The main issue is that most mobile devices offered by will never get their browsers updated. This shitty support for updates and standards turns the mobile web into those with and those without, where those without are forced to black text with white background. Sadly, this causes phones to be a consumable resource. With an iPhone at least people feel the need to get an updated firmware for new features. I could hardly say that about a Moto Q, or a BlackBerry Storm.

    Just from my experience, when at work I’m on a modern browser. When at home I hardly have time to sit down at a computer. Mobile browsing and apps become my social connection. Focus on restful APIs and useful mobile interfaces. Mashups and Apps are the future. Don’t worry about the old browsers. Just keep it fresh.

  4. Ami Ganguli wrote on :

    I’d say that most of the Mozilla sites are either technically oriented, or geared towards people using Firefox, so it should be fine to limit active support to the current versions of Trident (IE), Gecko, and WebKit, with Opera coming along for the ride due to being standards compliant. Even then, the IE8 support doesn’t need to be 100%. Technical people will understand if there’s a slight degradation while they’re using IE.

    But, the download pages need to reach a non-technical audience. That means at least IE6, IE7, and IE8 support for “download path” that starts with http://www.firefox.com.

  5. Gerv wrote on :

    Sites can be divided into two types: sites where the user is doing you a favour by visiting, and sites where you are doing the user a favour by telling them something or providing them a service.

    For the first sort of site, you want to be as widely compatible as possible. It would be perverse for someone to try and download Firefox and for us to say “sorry, your browser is too old, our Download Firefox page doesn’t support it.”

    But for the second type, you can be more picky. You can say, for example, that as long as a browser is free-as-in-beer (as all the major ones now are), you will only support the latest version, and encourage everyone else to upgrade.

  6. Mark Caudill wrote on :

    As a few have said, while I do understand the importance of choosing one model for all sites and not diverging from that “we support these browsers” model, it can be truly agonizing when you want the landing page for downloading Firefox to be treated equally.

    The download Firefox page is really about one thing: conversion to Firefox. If it doesn’t accomplish that, there is a big problem. Nearly every other page (outside of the mozilla.com sphere) doesn’t need to support IE6 or even Firefox 2 (although, they should be heavily encouraged to upgrade to Firefox 3/latest if Firefox 2 is detected on Mozilla’s sites). Even a small banner saying, “Want a great visual experience? Upgrade to Firefox 3.”

    As the front-end code standards page you linked to said: “(branch off and declare continued support only for acquisition sites?)” for external tools with IE6.

  7. Jon-Mikel Bailey wrote on :

    This is always a dilemma for us. We strive to create the most universally user-friendly sites but sometimes you simply can’t have your cake and eat it to. Numbers certainly play a part in our decision but sometimes we simply have to come up with creative overall solutions that involve extra coding and also comprimise.