debugging version

This elastic layout is fully liquid within the limits of given 'min-width' and 'max-width' values, of which the 'max-width' value depends on the User's choice of font-size in his/her own browser.

The layout rely on a wrapper-div with 'width' in percentage, 'max-width' defined in em and 'min-width' defined in px, for supporting browsers.

Container-elements inside the wrapper-div have their widths defined in percentage of the wrapper-div, thus they are self-adjusting.

Internet Explorer

Internet Explorer 6 (and older IE/win versions) get a reworked, mode-independent, IE-expression for simulation of 'max-width' relative to User's choice of font-size default, and min-width at Author's chosen value. This seems to be a slightly unusual approach, although the basics can be found at max-width in Internet Explorer. The rest about the IE-expression used can be studied at min/max expression forStrict/Quirks modes, and making IE/win work, with IE-expressions.

This layout will work fine in IE6, providing the User's font-size setting is respected and User has activated javascript. Fallback to fixed, em-based or fully liquid width is easily implemented, and is used in this page to set a width of 60em in IE5/Mac.

Important: This solution does not work in IE6, if there's even the slightest hint of Author's font-size choice declared on html, body or wrapper-div. It doesn't matter how Author declare font-size on those layout-carrying elements, there simply can't be any declared font-size on those elements since Author's choice will replace User's defaults in the IE-expression and mess up the calculation. That's how IE/win works.

There's no such limitation on elements further in, but font-sizes should be defined in '%' of base-font - which is User's default.

basics for wrapper:

  • width: 99%;
  • max-width: 60em;
  • min-width: 552px;

Complete CSS found in source-code

created:

  • date: 29. May. 2006
  • by: Georg Sørtun
  • updated: 31. May. 2006
  • updated: 18. Jun. 2006
  • updated: 03. Aug. 2006
    (this version)

good behavior confirmed in these browsers:

  • Safari 2.0.3
  • Firefox 1.5.0.3
  • Opera 8.52 & 9.00
  • Netscape 8.1
  • IE6.0.2800
  • IE7.0.05346 beta 2

navigation

This column is designed to drop if it's running out of space.

The problem: It has been reported that Gecko-based browsers may occasionally make this floating column drop – even if it is not running out of space.

The drop-bug is now confirmed in some alpha level builds of future Firefox versions. I'm not loosing any sleep over failures in any of those, but I am still looking for a reason, or bug, that may explain such a float drop in Gecko.

Looks like the problem is solved. It was related to the timing and sequence in Firefox' CSS table calculations - which is buggy.