Browser Compatibility Development Guide, Page 3
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.
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.
7. Utilize Firebug and Web Developer Plug-ins
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.
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