An important development goal of qooxdoo 0.8 is to resolve the box model issues of previous versions. qooxdoo should work in all types of web pages, standard-compliant or not. The box sizing itself is easily controllable by CSS in Safari, Opera and Mozilla.

In Internet Explorer there are two options available, but these work globally and do not allow for a per-element decision. In previous qooxdoo versions the only way to let Internet Explorer correctly handle the qooxdoo-calculated layout was to force the IE rendering engine to work in the so-called quirks mode. This can be achieved using an old or non-standard doctype. Even a non-existing doctype works well.

However, by decision of the Microsoft developers, in the IE quirks mode many new features and rendering improvements are not available. They are only available in standard-compliant mode e.g. XHTML-1.1. This includes things like min-width, max-width, margin and float fixes etc.

To become independent of the box model qooxdoo first needs to know the difference between the two models content-box and border-box.

• border-box (IE) means that a dimension is applied to the full box including the border and padding.
• content-box (W3C) applies the dimension exactly to the content excluding borders and paddings.

Most developers usually prefer the border-box as the more intuitive way to work with. To quote Paul Peter Koch: Logically, a box is measured from border to border. Take a physical box, any box. Put something in it that is distinctly smaller than the box. Ask anyone to measure the width of the box. He'll measure the distance between the sides of the box (the 'borders'). No one will think of measuring the content of the box.

Unfortunately, content-box is the so-called W3C model and the default in all browsers except IE, where the box model depends on the quirks/strict mode. IE uses content-box in strict mode (as all the other browsers do), and border-box in quirks mode (since it was the long time standard in IE). For a further reference you should read Paul Peter Kochs summary document.

qooxdoo version prior to 0.8 use border-box in all browsers in order to unify the layouting, mostly by the time of the early qooxdoo layout engines this box model was regarded more intuitive and logical. However, this decision required application developers to deliver a quirks mode document to IE users, which is not optimal for the reasons given above.

A further, often forgotten fact for box model specific layouting is that box-sizing does not work reliably or is full of bugs in combination with min-width/max-width and the corresponding height properties. This especially applies to Mozilla and Opera.

The box-sizing behavior is only relevant for nodes which apply a padding and border. Otherwise box-sizing has no effect. In qooxdoo paddings of parent widgets are often applied by calculating the (offset) position of the children accordingly. A real padding in terms of CSS styles is not applied to the DOM node in those cases.

qooxdoo applies the border directly to the outermost DOM node of a widget. This works well for many styles. The only restriction is that multi-color borders are not easily possible. For example, a perfect looking 2 pixel outset border consists of a light and a dark variant of the same color. To apply this advanced border qooxdoo uses the border-colors property in Mozilla. But for all other browsers qooxdoo needed to implement another solution: an inner element is scaled to 100% both in height and width. The inner, darker (”shadow”) colors are applied to the borders of the inner node. While this is a bit awkward, it works quite well and allows qooxdoo to create almost identical 2-pixel borders across all browsers.

Given this information and the new restriction to omit a border to the outermost element it should be possible to apply all border related things to special “inner” nodes instead of the outermost box. As an added benefit this should also allow for all kinds of complex borders, rounded corners, shadows etc. They could be implemented using inner DOM nodes, embedded Canvas/SVG, or any other technology.

In summary this strategy of omitting combinations of border/padding definitions and dimensions would mean to solve all box model issues and also allow for complex border styles.