Consistent Browser Display

A common design requirement for a web application is that the application should, so far as possible, look and behave the same in different web browsers. While not essential, having an application that looks and behaves identically irrespective of the browser offers a number of benefits. For example, users that use an application in different browsers (home and work) will be more productive, and documentation and support requirements will be reduced.

To help achieve the goal of developing web applications that have a consistent look and feel, both the System and Chameleon skin widgets in the Backbase Client Framework are themselves designed to appear and behave the same in all supported web browsers. However, in order to achieve the intended degree of cross-browser compatibility of widgets, certain restrictions need to be placed on the application's use of the DOCTYPE declaration.

This document begins with a review of the two CSS box models in common use and discusses the box model that is required for full compatibility of Backbase widgets. The document then explains the implications of the choice of box model on the use of DOCTYPE declarations, and explains how to set the box model selectively in non-IE browsers. Finally, some of the consequences of supporting the traditional box model in IE 6+ are presented.

Box models

One of the major factors contributing to differences in the appearance of page content is the fact that different browsers may apply a different box model. Two box models are in widespread use, the CSS1 box model (i.e. the box model implied by the CSS1 specification) and the traditional box model (the model that was originally used in Internet Explorer). To understand the difference between the two models and how this can give rise to difference in rendering of page elements, it is important to realize that the position and dimension of all HTML elements is defined in terms of a box consisting of (i) a margin, (ii) a border, (iii) padding and (iv) the content area (see Figure 1). There are separate CSS properties that can be used to set the widths of the margin, border and padding regions. The overall width and height of an element can be specified using the width and height properties. The differences between box models concerns how the width and height are interpreted.

Figure 1: The different width definitions used in the CSS1 and traditional box models

According to the CSS1 box model, the width and height properties refer to the dimensions of the element's content area. Thus, if a non-zero border or padding are specified, the actual dimensions of the element (measured from the outer edges of the border) will exceed the values specified in the width and height properties. By contrast, in the traditional model the width and height properties refer to the element's total width and height, that is, the sum of the dimensions of the border, padding and content areas. In situations where different browsers apply different box models to the page content, elements rendered according to the CSS1 model will tend to have larger dimensions.

Note: Elements without a border and padding will have the same dimensions in both box models).

It is clear from the above discussion that for elements to appear the same in different browsers it is generally necessary to ensure that the same box model is applied. More specifically, when using Backbase Client Framework's System and Chameleon skin widgets it is necessary (for full compatibility) to ensure that the widgets are rendered using the traditional (non-CSS1) box model. The primary reason this model was selected was to provide users with more intuitive control over the dimensions and placement of widgets. Figure 2 below shows the effect of the box model on the rendering of a Chameleon skin window widget. In the left panel the window is rendered using the traditional box model. In the right-panel the CSS1 box model is used.

Figure 2: The window widget rendered according to the (a) traditional box model and (b) CSS1 box model

While using the CSS1 box model results in significant rendering issues for the window, many System and Chameleon skin widgets will continue to work satisfactorily in both skins. However, one common issue affecting almost all the widgets is that their outer dimensions will exceed the values specified in the width and height attributes. Widgets that have serious rendering issues in standards-compliant mode are listed below in table I.

Widget Issues
accordion Very poor rendering of chameleon skin in IE 7; missing/misplaced bottom border
modal Incorrect dimensions for overlay/mask, close button does not work in IE6; dialog has unnecessary scroll bars
panelLayout Content may be cropped
tabBox Text may be partially cropped in Chameleon skin, tab control does not indicate which tab is active in System skin
window Buttons do not function in System skin in IE6; bottom border missing in Chameleon skin; text may be cropped

Table I: Widgets having severe rendering issues in IE6 and 7 in standards-compliant mode

Selecting between box models

The method for selecting which box model should be applied when rendering HTML elements differs fundamentally between Internet Explorer 6 & 7, and non-IE browsers (IE 5.5 and earlier do not support the CSS1 model). In IE 6 and 7, the box model can only be set at the document level using the so-called DOCTYPE switch. As a result, all elements when displayed in IE are rendered using the same box model. In recent versions of the other main browsers (Firefox, Opera and Safari), the box model can be set on an element-by-element basis using the proposed CSS3 box-sizing property (or proprietary equivalents). Setting this property to content-box will result in the element being rendered using the CSS1 box model, while the traditional model is specified using the value border-box. Note that the proprietary Firefox property -moz-box-sizing can also have the value padding-box. Table II below summarizes the different methods for specifying which box model to apply.

Browser Method for switching box model
IE 5.5 no support for CSS1 box model
IE 6 & 7 a valid DOCTYPE is required force the CSS1 model
Firefox 2+ -moz-box-sizing
Safari 3 -webkit-box-sizing (also -khtml-box-sizing)
Opera 9 box-sizing

Table II: Support for different box models in popular browsers

Since the box model can be specified at the level of an individual element in recent non-IE browsers, the appearance of Backbase widgets in these browsers should be relatively unaffected by the presence or absence of a document type declaration. By contrast, the inclusion of a valid DOCTYPE will have a significant adverse effect on the appearance of widgets in IE6+. The table below summarize the DOCTYPES that result in IE6+ switching into standards-compliant (strict) mode (the mode in which the CSS1 model is applied).

Note: For HTML specifications prior to 4.0, the inclusion of a DOCTYPE does not switch the browser into standards-compliant mode.

Label Definition URL present URL absent
HTML 4.0+ None Strict Strict
HTML 4.0+ Frameset Strict Quirks
HTML 4.0+ Transitional Strict Quirks
HTML 4.0+ Strict Strict Strict
XHTML - Strict Strict
XML - Strict Strict
unrecognized DOCTYPE - Strict Strict

Table III: Effect of different DOCTYPEs on rendering mode

It is important to realize that a DOCTYPE declaration will only result in IE switching into standards-compliant mode if the declaration occurs on the first line of the document. As a result, a relatively simple method of ensuring that the traditional box model (the model required for correct rendering of Backbase widgets) is used in IE 6+ is to include an empty comment as the first line of the document (see Snippet 1).

<!-- -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
        <head>
                <meta http-equiv="Content-Type" content="text/xhtml; charset=UTF-8"/>
                ...
        </head>
        <body>
                ...
        </body>
</html>

Snippet 1: Using an XML comment to prevent IE from using standards-compliant mode

Standards-compliant versus compatibility mode in IE

The DOCTYPE switch as a method for changing browser rendering behavior was introduced in IE 6. The purpose of switch was to provide web authors and developers with a means to ensure that changes in the interpretation of various CSS properties (and numerous bug-fixes) introduced in IE 6 did not break the appearance of existing web pages and applications. When a suitable DOCTYPE declaration is not included on the first line of the document (see Table III), the document will be rendered in the same way as it would in IE 5.5 (referred to as compatibility or quirks mode). In particular, the traditional box model will be applied to all elements, and various other CSS changes and bug-fixes introduced in IE 6 and IE 7 will not be applied. Only when a suitable DOCTYPE declaration is used (referred to as standards-compliant mode) is it possible to take full advantage of changes in IE 6 and 7.

Some of the differences between standards-compliant and compatibility modes when running IE 6+ are given below in Table IV.

Description Standards-compliant Compatibility
element which serves as the canvas HTML BODY
background can be applied to HTML element yes no
support for the pre value of the white-space property yes no
stricter stylesheet parsing yes no
padding properties supported on IMG elements yes no
inline elements do not support setting of width and height true false

Keep in mind the following points regarding strictModeCompliance:

  • One of the major factors affecting the appearance of HTML elements is the CSS box model used to render them;
  • The two box models in common use are the CSS1 model, and the traditional model;
  • The System and Chameleon skin widgets are designed for use with the traditional box model;
  • In IE 6+, including a suitable document type declaration on the first line will force the page to be rendered using the CSS1 model;
  • To ensure correct rendering of System and Chameleon skin widgets, any DOCTYPE declaration should be preceded by an XML comment (see Snippet 1).

Additional Resources

For more information on SOAP, refer to the following documentation: