March 3, 2021
Hot Topics:

Browser Compatibility Development Guide

  • By Jeff Ryan
  • Send Email »
  • More Articles »

Browser Compatibility Design and Development Best Practices

The following is a starter list of best practices for browser compatibility design and development.

1. Use Firefox as the primary browser for development
The Mozilla team designed Firefox to support W3C standards from the ground up. Because Firefox adheres more strictly to standards, it is much easier to develop a web application on Firefox and then get it to work in Internet Explorer than the reverse. Development IDE such as Eclipse should be configured so that Firefox is the default browser.

2. In development, periodically test the application in Internet Explorer and other supported browsers
Throughout the development phase, test the application in IE. Prior to Quality Assurance, thoroughly test the application in IE. Utilize your onsite or remote compatibility lab to test different versions within the supported browser families.

3. Use IE as the primary browser for Quality Assurance
A significant percentage of end users prefer Internet Explorer. Quality assurance testing the application developed primarily with Firefox on IE will ensure that any IE compatibility issues missed by developers in their unit testing will be identified. The application should also be regression tested versus all supported versions in the IE and Firefox browser families as well as other formally supported browsers.

4. Specify a DOCTYPE to explicitly declare the structure of the web page
A DOCTYPE specifying strict use of HTML or XHTML is recommended. Not being careful in the DOCTYPE declaration can throw a browser into what is known as "Quirks Mode" which allows invalid and vendor specific markup. A page developed unknowingly in quirks mode will not render consistently if at all with other browsers. The strict DOCTYPE keeps you honest in adhering to standard and valid markup document structure.

In Firefox, the "Page Info" dialog box (available from Tools, Page Info) specifies the rendering mode currently in effect. In addition, the document.compatMode property can be checked programmatically.

Although a "strict" DOCTYPE and standards compliance mode are recommended, each project must determine the level of warnings which are acceptable. It is quite possible to have an application that works fine with Firefox and IE, but still has items flagged by validators such as missing alt tags.

5. Utilize global CSS to separate document structure from presentation and to abstract browser presentation differences
Utilize CSS libraries to control the presentation across the site and encapsulate browser differences in the box model which controls white space around block level elements. Any presentation code such as font tags should be forbidden from the markup document and included in the CSS.

6. Use 3rd party libraries in lieu of custom JavaScript code for cross browser support
If you find yourself writing cross browser code, it should raise a red flag. It is a much better practice to use a 3rd party library which has been built and tested for cross browser support. For example, Ajax solutions such as Dojo provide JavaScript libraries which were built from the ground up for cross browser support and accessibility.

7. Utilize Firebug and Web Developer Plug-ins
The Firebug and Web Developer Plug-ins provide a wide variety of features designed to help validate, analyze, debug and correct browser compatibility issues. Try to avoid putting alerts in your JavaScript and markup for debugging which must later be removed. It is very easy to inspect and manipulate the structure, presentation and behavior elements of your web page at run time using these tools.

8. Develop a Browser Compatibility Knowledge Base
Create a Browser Compatibility Knowledge Base to catalog and share browser compatibility lessons learned, perhaps beginning with the previous seven items outlined here. This knowledge base can be as simple as a shared document or wiki.

Browser Compatibility Design and Development Pitfalls

The following is a starter list of pitfalls to avoid in the design and development of cross browser applications.

1. Avoid browser specific plug-ins - The whole purpose of creating cross browser applications is not being tied to a specific browser family. Browser specific plug-ins such as ActiveX controls are a detriment to compatibility.

2. Avoid code forks - If you find yourself coding JavaScript which says if(isIE6), you are introducing a fork, and a non standard feature into the web application. This will create duplicate development, QA, maintenance and production support activities. In addition, this code is likely to cause additional re-work as new IE or Firefox versions are introduced or other browsers such as Chrome or Safari are supported.

Your first course of action is to use standards to meet the stated requirement. If the requirements cannot be met without standard features, then it is better to create a fork which tests for a particular feature such as if (document.getElementById).

3. Not considering the implications of what CSS hacks are used - CSS hacks take advantage of browser deficiencies in supporting standards. These hacks may be used to encapsulate browser compatibility issues. However, care must be used to ensure they do not create maintainability issues, nor impede behavior in future browser versions.

Page 3 of 4

This article was originally published on June 25, 2009

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date