Browser Compatibility Standards
From Web Smart Newsletter: Browser Battles
Originally published July 2002 - Updated July 2006. By Eric Holter.
Originally published July 2002 - Updated July 2006. By Eric Holter.
The first step in handling browser compatibility issues is clearly defining which browser a given web site will support. For us, when a browser's use drops below 3% we no longer actively support it. That does not mean that a site won't work in an older browser. It just means we no longer test with that browser and if display issues arise we do not automatically fix them.
While we form our standards based on the most actively used browsers, and in 95-97% of cases our sites will look great, that doesn't help when our client just happens to be one of the few web users still using an antiquated browser. While we always include our browser compatibility standards in our proposals, it's also a very good idea to ask a prospect or client what browser they use (and perhaps more importantly, which browser their boss uses) before beginning a project. Otherwise you will be facing a real problem toward the end of a project when the client calls saying the site looks awful on their computer (not the time to begin educating them on browser compatibility issues).
Supporting the most widely used browsers and using the most efficient means of coding makes perfect objective sense for web projects. However, the decision to limit browser support might not make sense to those people who still happen to use older browsers (this is particularly problematic if the CEO happens to be one of those people). This is why it is extremely important to communicate and discuss browser compatibility standards with your client before a project begins. It's also a good idea to include browser compatibility standards in any proposal or project contract. And please, always ask the question "what browser does the president of the company use?," and maybe what browser her Mom uses.
So what happens when one of the 3% hits the website? Our policy is to make sure the site is still usable (visitors can access information) in the older browsers, even though there may be significant display issues that might make the site look bad. In some cases, we have employed the technique of using a pop-up window to alert the user of an older browser, letting them know that the site was built for 5.0 and up. The window provides a link to download a current browser.
One other note regarding communicating browser standards relates to future browsers. At Newfangled, we include the following text in our technical standards, "Newfangled does not guarantee compatibility with future releases of the various browsers. If new browsers do not display information accurately fixes can be made at our hourly rate." While this may seem obvious (how can you support a browser that doesn't yet exist), it's a good idea to let a client know that future releases of a browser may act differently theorectically "breaking" the existing site. When Netscape 6.0 was first released this was a major problem (that particular browser was unusually buggy, but the Netscape 6.01 release fixed most of the bugs).
While browser compatibility issues are by far the most frustrating part of web development, things have improved. The good news is that with every month that goes by, there are fewer older browsers being used. To our great releif the current trend in browsers is toward cross-browser compatibility and adherence to the existing web standards. Hopefully with less pressure for new releases of browsers to offer new and unique capabilities, the newer browsers will remain compliant with existing standards. One can dream, can't he?
While we form our standards based on the most actively used browsers, and in 95-97% of cases our sites will look great, that doesn't help when our client just happens to be one of the few web users still using an antiquated browser. While we always include our browser compatibility standards in our proposals, it's also a very good idea to ask a prospect or client what browser they use (and perhaps more importantly, which browser their boss uses) before beginning a project. Otherwise you will be facing a real problem toward the end of a project when the client calls saying the site looks awful on their computer (not the time to begin educating them on browser compatibility issues).
Supporting Older Browsers
Supporting the most widely used browsers and using the most efficient means of coding makes perfect objective sense for web projects. However, the decision to limit browser support might not make sense to those people who still happen to use older browsers (this is particularly problematic if the CEO happens to be one of those people). This is why it is extremely important to communicate and discuss browser compatibility standards with your client before a project begins. It's also a good idea to include browser compatibility standards in any proposal or project contract. And please, always ask the question "what browser does the president of the company use?," and maybe what browser her Mom uses.
So what happens when one of the 3% hits the website? Our policy is to make sure the site is still usable (visitors can access information) in the older browsers, even though there may be significant display issues that might make the site look bad. In some cases, we have employed the technique of using a pop-up window to alert the user of an older browser, letting them know that the site was built for 5.0 and up. The window provides a link to download a current browser.
Handling future browsers
One other note regarding communicating browser standards relates to future browsers. At Newfangled, we include the following text in our technical standards, "Newfangled does not guarantee compatibility with future releases of the various browsers. If new browsers do not display information accurately fixes can be made at our hourly rate." While this may seem obvious (how can you support a browser that doesn't yet exist), it's a good idea to let a client know that future releases of a browser may act differently theorectically "breaking" the existing site. When Netscape 6.0 was first released this was a major problem (that particular browser was unusually buggy, but the Netscape 6.01 release fixed most of the bugs).
What does the future hold?
While browser compatibility issues are by far the most frustrating part of web development, things have improved. The good news is that with every month that goes by, there are fewer older browsers being used. To our great releif the current trend in browsers is toward cross-browser compatibility and adherence to the existing web standards. Hopefully with less pressure for new releases of browsers to offer new and unique capabilities, the newer browsers will remain compliant with existing standards. One can dream, can't he?
![]() |













