Browser Compatibility Development Guide June 25, 2009 Introduction Creating cross browser web applications impacts the entire Software Development Life Cycle (SDLC). Impacted roles include project managers, web designers, architects, developers and quality assurance. This guide for browser compatibility development has been designed to answer the following questions about developing cross browser web applications: Is the browser compatibility problem a business problem? What is the recommended browser compatibility solution? What browser families do I need to support? What environments and tools are required? What are design and development best practices? What are design and development pitfalls? What additional resources are recommended? The goal of this article is to provide the information needed to start or enhance a browser compatibility development practice in your organization. Browser Compatibility Now and Then At the turn of the century, web developers created applications which worked across Netscape and Internet Explorer (IE) browser families as each browser competed for market share. This was an arduous task due to evolving web standards and the lack of adoption across vendors. In the ensuing years, Internet Explorer won the market share battle, but not the war. The additional effort for building applications to work with Netscape was not warranted for many applications. From the perspective of market share, the current situation looks much more like 2000 than 2003. There are now two very popular browser families, IE and Firefox. Other browsers such as Safari, Chrome and Opera have a significant presence as well. From the perspective of web standards, it is a totally different game. Browser standards are stable and mature. Their adoption across vendors is very broad. While not a trivial task, it is much easier today to build web applications which work across browser families if standards are followed. Browser compatibility is more of a developer than a vendor problem today. The Browser Compatibility Problem Wikipedia defines "cross browser" as the ability for a website to support multiple web browsers. This is essentially what we mean by browser compatibility. In the past, new features were added to IE and Netscape without any coordination between vendors. This resulted in differences between how features worked ranging from slight cosmetic differences to profound conceptual differences. Today, the maturity and adoption of web standards by vendors has standardized the feature set to a great extent. This is fortunate because the marketplace demands browser agnostic web applications. If your organization creates applications tied to a specific browser, it puts itself at the risk of turning away consumers and partners who prefer to interact with a particular browser. This is the browser compatibility business problem. If your website does not render or operate correctly on a user's browser, it negatively affects your organizations image and brand. This means your applications should be browser agnostic to the highest degree practical. The Browser Compatibility Solution In the past, the requirement for cross browser applications was solved for by creating "forks" in the code to handle the peculiarities of supported browsers. This made it costly and difficult to create and maintain websites due to the redundant development and testing of the various code branches. When new browser versions were introduced, poorly designed forks often created additional work due to the change in browser behavior. Web standards provide a much simpler solution for building cross browser applications. The web application is designed from the start to support web standards--not a particular browser. To a certain degree, this future proofs the web application from the introduction of new browsers and browser versions. Structure, Presentation and Behavior Standards There are three sets of World Wide Web Consortium (W3C) standards which describe the structure, presentation and behavior of a web page. There is also a key Ecma standard tied to manipulating the behavior. The structure of the web page document is defined by markup language standards (HTML, XHTML, XML). The DOCTYPE descriptor tells the browser what document type definition to use in validating the structure and how strict to apply validation rules. The following DOCTYPE statements instruct the browser to strictly adhere to the HTML 4.01 and XHTML 1.0 specifications in validating the page. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"> The presentation of the web page uses the CSS standard to control the colors, fonts and layout. CSS separates the content described in the document structure from how it is viewed in different contexts. The behavior of the web page is controlled by the ability to manipulate a standard document object model (DOM) representation of the structure and presentation elements. ECMAScript, the standard version of JavaScript is the standard language used to manipulate the object model. Adherence to structure, presentation and behavior standards (and not vendor specific adaptations of these standards) is the essence of the browser compatibility solution. What Browser Families Should You Support? You need to consider which browser families, operating systems and configurations are preferred by your customers, partners and employees. In order to understand your audience specifically, you will need to examine the web analytics particular to your web application. There are many industry resources which provide browser usage analytics. These should be reviewed regularly to stay top of trends. An example is the following W3C website:http://www.w3schools.com/browsers/browsers_stats.asp. In general, Firefox and IE are the most popular browsers. A good starting point in your browser compatibility practice is to minimally provide formal support for these two browser families, meaning you will fully verify them through the entire software development life cycle. By following web standards, you will be well positioned to support additional families such as Chrome, Safari, Opera or others if required by your audience with minimal additional effort. In addition to the browsers supported, you should also pay attention to the types of devices and operating system versions being used as well so you can test your applications in environments similar to those being used by your customers, partners and employees. What Environments and Tools are Required? A browser compatibility solution requires the properly configured development and quality assurance environments to support web designers, architects, developers and quality assurance personnel throughout the software development life cycle (SDLC). Development Environment Web designer and developer desktops will need to be configured with the primary supported browsers. Firefox and Internet Explorer should be considered at minimum. If your audience demands it, other browsers such as Chrome, Safari and Opera should also be included. Because Firefox more strictly adheres to structure, presentation and behavior standards, it should be the primary browser for development. Firefox should be configured as the default browser on the desktop and in your IDE (Integrated Development Environment), for example, Eclipse. Although Internet Explorer is not the primary browser, it should be utilized in unit testing. Debugging tools are essential in developing cross browser applications. Firebug and Web Developer are two essential plug-ins which should be included in your Firefox configuration. A rich toolset and plug-in ecosystem is another advantage of the Firefox browser for designers and developers. QA Environments Quality assurance environments may be provisioned on site, or remote services may be used. A remote service may be useful for testing odd or uncommon browser and operating system combinations. Whereas developers and designers should be using Firefox as their primary browser, quality assurance personnel should spend more time with Internet Explorer. This creates balance in the development and testing activities across the primary browser families. 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. Summary Browser compatibility is more than a technical problem. It is a business problem. If your website does not render and operate properly on the browsers your customers and partners prefer to use, it may harm the reputation of your organization and turn customers away. Ensuring browser compatibility of your web applications begins with understanding your end users needs. Compatibility development standards and practices to meet these needs must be defined for your organization and embedded into the entire software development lifecycle. Creating browser compatible applications affects the day to day job of project managers, web designers, architects, developers and quality assurance personnel. Web standards which define the structure, presentation and behavior of a website are the cornerstone of a browser compatibility development practice. Adhering to these standards make what was once a very arduous job more manageable. The proper environments and tools are needed for developers and quality assurance personnel to test for browser compatibility and to debug problems. These tools and environments should be designed and configured to simulate the user experience of your audience. There are a number of best practices and pitfalls shared in this article. Creating a browser compatibility knowledge base will help capture the lessons learned and to share them with the broader development community. Do you have the statistics which show what browsers your customers, partners and employees prefer to use? Do you have defined standards for creating web applications which will support these browsers? Do you have the appropriate environments and tools to test and debug for browser compatibility? Do you have a knowledge base to share lessons learned and best practices? If your answer is no to any of these questions, consider using the information presented here to start or enhance a browser compatibility development practice in your organization. The rest is up to you! Browser Compatibility Resources Anyone wanting to study browser compatibility in more detail would do well to start here. Developing Web Applications Using Standards Designing With Web Standards by Jeffrey Zeldman Migrate Applications from IE to Mozilla by Doron Rosenberg Using Web Standards by Mozilla Web Standards Checklist by Max Design The Business Benefits of Web Standards by Mozilla Validation Services W3C markup validation service W3C CSS Validation Service Mozilla DOCTYPE Sniffing