I do freelance web development and front end dev is not my strongest point. This question came to me in my recent fixed bid project.

Nowadays we use Jquery and Bootstrap and these take care of lots of cross browser stuff. Still, there are lots of errors in different browsers. It requires testing tools and a whole lot of other things to worry about.

Should it be explicitly mentioned that the resulting site should be tested for cross browser compatibility in a contract? Or

Does it come by default in the scope of the project?

How can we estimate hours spent in cross browser compatibility?

Edit: Some great answers here. But how should a scenario be handled when no browser discussions happened at all at the time of signing contract?

  • Having provided a number of Intranet sites a requirement has often been that only the Official Corporate Authorized Browser is supported. Typically only a single version thereof need work correctly and, being Corporate, it usually isn't the most recent version.
    – HABO
    May 29, 2013 at 12:09

5 Answers 5


In your contract, you should specify an explicit list of supported browsers. This will save you a lot of trouble, if later the customer complains that the page looks broken on his stone-age Windows XP notebook with IE6. (Read what happened to this guy.)

Since you use libraries, the intersection of their browser compatibility lists (jQuery, Bootstrap) is probably a good starting point for your own list. Be sure to mention specific browser versions rather than minimum versions: If, in two years from now, a new IE/Firefox/Chrome version is released that renders your webpage incorrectly, why should you have to fix it for free?

As soon as you include a list of supported browsers, testing for these browsers (and fixing any problems due to use of those browsers) is part of the project. Compatibility with other browsers is not in the scope of the project and must be ordered and payed extra.

The time (and cost) for this varies widely, depending whether it is, for example, a small fix for a tablet-variant of some recent webkit-based browser (low price) or adding IE6 compatibility to a complex HTML5 webpage (very high price).

  • 1
    +1 great answer, especially the bit about "specific versions"
    – ozz
    May 30, 2013 at 12:23

As a client, I would expect the website to be compatible with the "Top 5", i.e. Chrome, Firefox, Opera, Safari and IE8+.

As a freelancer, my opinion vary depending on the budget (unless the initial requirements specify explicitly the compatibility, in which case the question doesn't exist in the first place).

  • If the customer is one of those who don't have money and don't want to pay for quality and the project is on the lowest possible budget, I will ensure that the website works well in the browser I use myself. "It works on my machine", that's all I need. If you need compatibility with another browser, that will cost you additional N dollars.

  • For ordinary projects, I would at least ensure that the project works with the latest versions of Chrome, Firefox and IE; maybe I'll also try a previous version of IE, but won't spend too much time tweaking the layout for it.

  • For high-quality projects, I would require the list of browsers to be specified in the requirements. This makes things very clear, and the customer may ask even the compatibility with IE6, if he wants to pay twice the price of the project.

    If browser compatibility is important, a study may also be done to gather/predict browser usage statistics. This would make it possible to determine precisely what browsers should be taken in account. Spending days on a bug within IE7 doesn't make sense if IE7 is used by 1% of the customers.

Note: what's also very important is how compatibility will be tested. If rounded corners are not rounded in IE7, while the requirements require the website to be compatible with IE7, does it violate the requirements? If a zone is 2 pixels larger on a browser compared to another, given that this discrepancy is barely visible, does it matter and should it be fixed? If only an ugly hack can fix a specific discrepancy, should it be used, or should the clarity of the code be the priority?


A working approach is to classify the browsers as the BBC did in BBC Browser Support Standards.

I use these classes:

+ supported (≥5%)
o partially supported (≥2%)
- not supported
● tested by me

The customer gets a chart with browsers, versions and marketshare, with each entry marked according to the legend above. I test only with the newest version of each of the three market leading browsers.

Supported browsers are those with a market share of at least 5%. For these, I guarantee functional and visual compliance to the client's specifications. Any deviation is considered to be a bug, I have to fix.

Partially sopported browsers are those with a market share between 2% and 5%. I guarantee only functional compliance. Any functional deviation is a bug, everything else a change request.

Unsupported browsers are what the name says - not supported. Anything the customer wants me to do in this area is a change request, he has to pay for.


Yes, you should specify what browsers will be supported by the resultant web site, ESPECIALLY on a fixed-price bid job. Your client may well have a good handle on their users, in which case they may be able to tell you what browsers they care about.


There's another answer to this, they're called ratified standards... Agree up front which standards you're working to (xhtml1.0 transitional/css2.0 for example) and develop to that. The standard itself is the final arbiter and changes in later browsers should take those changes into account.

Doing this takes you out of the situation where if a browser maker changes functionality as a patch (especially in a draft standard like html5 which is likely to change) then you're not caught out. Equally if two render engines don't tally up then you have a fixed point of reference as to which behaviour is correct.

If you then want to add nonstandard code or use additional features targeting some non-standard browser behaviour like chrome or ie6 then you can do so in an additive way (through feature detection for example.)

If the client comes back with a problem then you can point them to the standard and say it's doing what it should but if you'd like me to update it for your chosen non-compliant platform then I'll be happy to, but it's going to cost you.

(* IE6 and Chrome are equally problematic as bad developers target browser specific features and don't code to fall back to a standard appropriately.)

  • I see a potential pitfall in following ratified standards. Client can say that they don't know about standards and I am just trying to get more money from them. In fact this has happened to me once when the client said how could he trust my estimates. Needless to say I stopped working with client after that. Anyways mentioning browser versions seems more apt. What do you think?
    – codecool
    May 29, 2013 at 16:15
  • @codecool - I think it sounds like your problem was the client didn't trust you and that's a whole other ballgame. Clients rarely know anything - that's what they hire us for and if you can point them to a specification then even they don't understand it they can check it with someone else, that's not so easy with working around moving targets like browser versions. Besides, bad devs using non-standard functions are how we ended up with clients being stuck on old technology... We all have a responsibility to make sure we don't go there again. May 29, 2013 at 22:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.