The search for a technique that offers real equal height columns leads nowhere because we don't have full vertical control in current CSS 2.1 implementations cross browser. The available techniques are simulations of columns: a repeated image displaying Faux Columns [Cederholm], columns made of borders [Livingstone], and variations.
We couldn't even fall back on a (CSS-)table, since there is no broad, sufficient implementation of
display: table in the browsers. And a table would dismiss the accessibility request for having the columns logically ordered in the source.
OneTrueLayout [Robinson] uses a promising technique [Challoner] where the columns are still not equal in height, but they are cut in length, so they appear as-if. Surprisingly, this trimming made problems that are not solved.
In this article, we draw up a variation for the equal heights columns illusion, standing on the shoulders of OneTrueLayout. Both techniques use excessive padding and compensating negative margins, a tricky concept.
Imagine the margin edge and the padding edge of an element. Most analogies with things of the real world would assume the margin box as equal or bigger than the padding box.
This margin edge or outer edge is the contact line with the surrounding elements, it is the physical borderline.
What happens if we deliberately tighten the margin edge by a negative margin? Smaller than the padding edge? The borderline contracts, moves inwards. The margin box becomes smaller than the padding box. The padding edge then sits outside of the margin edge of the element. But the surround still touches the margin edge.
This can make an element move, even “spill beyond” [Meyer], because we see the padding edge, the border and the content shifting in the direction of the invisible negative margin.1 Push or pull, it depends what angle you look at it from.
In the OneTrueLayout method [Robinson], floating columns of unknown height are wrapped by a container element. All columns get more length by an excessive padding. This would let the containing element expand in height. But the same length is subtracted from the columns by a negative margin. The excessive padding area now hangs out of the container that did not change its height. Finally,
overflow: hidden cuts the overhang on the bottom edge of the container.
overflow: hidden cannot be used for the “padding excess/negative margin compensation”-method without drawbacks: this property has some obscure requirements by the CSS2.1 specification. In newer browser implementations, the content shifts when an anchor inside is targeted (and the content scrolls on select-drag in older browsers) [Robinson].
The only other CSS2.1 property that is able to visually cut content,
clip, can be used on absolutely positioned elements only, and lacks broad correct implementation.
Not within CSS, but another way to cut the excessed padding is to let it run from bottom to top, into the void beyond the viewport's top edge [O'Brien]. Of course the content still must run from top to bottom. This requires two elements: each column needs its companion that is running in the opposite direction. The column holds the content, the companion performs the padding(plus) / margin(minus) operation, and the viewport's top edge replaces the
overflow: hidden to take away the overhang.
It is still the illusion of a real column. A visual column does not necessarily need to consist of one element only. Faux columns is a picture behind a column's content. The border column technique places the column content in front of a wide border. And we are trying to push a presentational column element underneath a content column element. Because we have two opposite directions, we can style the upper column and the lower companion, the top and the bottom of the resulting column illusion.
Authors may want to have the visual columns at different levels. It is a matter of determining the end of the content:
Either way, now we have the starting level, or the pedestal, for the columns' companions. While shooting up from bottom to top, the companion must not expand the pedestal.
In OneTrueLayout, the column had a padding-bottom excess and negative margin-bottom compensation. In our proposed technique it is the opposite direction: the companion of the column gets a padding-top excess and negative margin-top compensation.
If placed inside the pedestal, the negative margin-top forces the companion to start from the pedestal's top content edge, while the padding is placed in top direction, shooting up, and finally vanishing in the viewport's top edge.
The lower companions represent the background of the columns. Coming later in the source, the pedestal with the companions must not be nearer to the viewer than any preceding content (columns, header etc.). Otherwise, the column's content would be painted over by its background. Therefore, pedestal and columns (in conjunction with the header) need to swap their place in the stacking order by using
position: relative and an adequate
In any layout, the columns have to be arranged. Say the left column, following the center column in source, is 200px wide, a float with a negative left margin. So is its companion: it gets the same declarations for this horizontal arrangement by the same class. Horizontally, the companion moves like the column; they are dancing as a pair.
If content is to be placed inside the presentational companion, some problems have to be considered:
L, C, R,and the underlying companions as
L', C', R': the unstyled version of the page reads
L - C - R - L' - C' - R'without a connection between, say,
There are a number of ways to implement the method. A basic HTML structure could look like this:
<div class="center column">...</div>
<div class="left column">...</div>
<div class="right column">...</div>
</div><!-- stacker -->
<div class="center companion"> </div>
<div class="left companion"> </div>
<div class="right companion"> </div>
</div><!-- pedestal -->
</div><!-- page -->
Please refer to the examples for the complete HTML and CSS. Some notes:
#stacker-element, and use
z-indexon this one. (Opera < 9 does not respect z-index on relatively positioned floats.)
position: relativeto prevent itself from getting clipped by the pedestal in IE-Win [Bergevin et al.]. Safari 2.0.4 needs
position: relativeon the companion, too.
inside the companions. Don't use
height: 0for the companions as this may cause overlapping.
$big_valuefor padding and margin must not exceed
$big_value = 32767pxshows rendering inconsistencies on high dpi screen settings in IE6-7 when scaling is enabled [Fassino et al.]).
The column can be designed from top to bottom, while the companion has the opposite direction. A designer can apply a background image that is bottom-oriented to the companion, and a second image to the top of the column that holds the content. Visually, the column can take two background images.
With a layout not starting visually at the top of the viewport edge, there is something needed to cover the lower companions that are shooting up. This can be a header-element, the background of a containing element, a border of the body element ... anything that suits your layout.
We transferred the method to a number of layouts as a proof of concept. Note that the companion columns method cannot compensate for a layout's weakness in horizontal alignment.
In this article, we are introducing a technique for equal heights aspect of columns that could be transferred to various existing web page layouts.2 There is no grail, no 'one size fits it all' solution. We encourage users to review their requirements thoroughly.
The technique is a variation of OneTrueLayout's equal height columns method. The original method required the use of
overflow:hidden with unacceptable side effects in current browsers. Our variation introduces companions of the columns that expand from bottom to top with a top padding and negative top margin. The bottom starting point can be set with the footerStickAlt-method. We strongly recommend to read the articles that explain the methods we used.
This article cannot substitute for a comprehensive, clear article on negative margins - which has still to be written, although they are widely used in current layouts. We can only reflect certain aspects for a better understanding of the method.
This method uses some wrappers. They are design hooks, they align elements, contain and clear them, ease the padding requirements. And they manage browser bugs. There is an opinion that additional wrappers would be a bad coding practice. Those who secure this have to show the evidence that one div less should be better at all. We don't like the idea of having reduced the amount of wrappers to an absolute minimum for the requirements of a simple layout example just to see it break in real pages.