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).

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.)