Browser Compatibility Development Guide, Page 2
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.
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).
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.
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.
Page 2 of 4