Tech Info - CSS 3 Column Liquid Layout

These notes describe our experiences converting from our old liquid nested table layout to our current (since mid 2003) bright shiny CSS three column liquid layout.

Well it's not exactly crossing the Rubicon. But it was a great feeling. We had an relatively easy time converting our pages because we were able to avoid the most critical problems that many designers encounter since we are not a pixel-perfect site (though in 2004 we did a 5 layer, pixel perfect, CSS liquid layout). We've provided some notes to remind us what we had to do. If you find them useful - even as a 'what not to do guide' - then read on.

Design Requirement

We had the following design requirements:

• Single style sheet (actually not quite true because we serve up browser specific pages from our server).

• Support all our target browsers with a single page layout strategy (and roughly in this order of importance).

  • MSIE 5.5+, 6.x, 7.x
  • Gecko 1+
  • Opera 7.x
  • Default fallback mode

  Our HTML markup must be standard but we will allow browser-specific variations in the CSS style sheet. We conditionally generate pages based on minimal Apache Browser sniffing.

• Keep our current look and feel (OK, OK so there are down-sides to this approach).

• 'Sectionise' our page layout such that by ONLY manipulating CSS definitions we can change our page layout (probably an unacceptably high expectation).

• Minimise site wide changes or at least allow us to migrate at our pace.

First attempt - conclusions

The pages work and work well. But..

The Good

• The HTML markup is simpler and more obvious. We can probably go much further with this.
• We have avoided the tedious chore of table debugging that crops up from time to time with nested table designs.
• The absolute positioning has the side effect that we can place the menu 'divs' anywhere in the page that's convenient. For managed page generation this may turn out to be very important. We think it also provides good accessibility layout - by placing the central div first (the page meat) we have allowed page readers a much easier time.
• On heavy pages the central pane now displays as soon as it is loaded while we wait for the side panels.
• We have increased central style control which has got to be good news (doesn't it?).

The Bad

• We lost the right hand navigation menu in NS 4.x browsers.
• IOHO placement of Footers is a disaster in CSS. Be prepared to make compromises.
• We can break the central pane limits with long lines inside 'pre' tags and big tables neither of which is true for table layouts (we wish there was some kind of strict limit directive).

The Ugly

• To curb MSIE's desire to destroy page layout if it even smells 'width:100%' or 'width="100%"' in a 'div', we have to use a dummy nested div to control it. The nested div solution is harmless with every other browser we tried. Sigh.
• Having done this we now have a vague feeling of discomfort when we use absolute positioning. Maybe its our 'old-fashioned' notions of DHTML. Absolute positioning for Javascript effects, HTML was laid out in-line.

As of April 2003 we started to migrate the site to our CSS controlled (a.k.a 'table-less') layouts. We have a resonable migration scheme (with some overheads) so we can take our time. The benefits are too great - at least on our site.

What we did and what we got

Our experimental page and this page were the initial results of our attempts at 'table-less' layout. We spent a couple of days reading the web based material (a lot for us) and decided to try a pure CSS based layout. Our site is not pixel-perfect, nor do we use wide borders so a few pixels here and there is fine by us. This means that we avoid the serious problems of MSIE 5.x (it counts all borders and padding as being inside the 'box' not outside as it is supposed to do). Serious stuff if you need 'no-gap' layouts.

Our decision to include NS 4.x also caused some problems - but surprisingly few once we made one draconian decision!

You can look at the original page source and the table-less version. This is the style sheet.

Here is what we did

• We created five NEW styles to layout the three central columns, the banner and the footer, we called these 'l-c', (center pane) 'l-f', (footer pane) 'l-l', (left hand menu pane) 'l-r' (right hand menu pane) and 'l-b' (banner pane) which was initially just an empty placeholder.

• We decided to leave our top logo plus navigation bar as a table. It's really not significant at this stage (slapping it in a empty 'div' would have done absolutely nothing - though it proved to be essential when we moved to CSS pop-up, drop-down menus). Whether that disqualifies this as a table-less design is in our view moot.

• We used the glish.com 3 column layout as a starting point (which is both very simple and very effective), ripped out our three central layout tables replacing them with simple 'div's and clicked the refresh button!

• Left Hand Menu:

  .l-l {
    position:absolute;
    top:60px;
    left:6px;
    width:110px;
    z-index:1;
  	}
  

  Absolutely positions the left hand menu. This is a global definition and works for every browser in our list including hoary old Netscape 4.x. NOTE: The NS 4.x infamous 'width' limitation is only inside 'tables' and since we are 'table-less' we have no problems. Ah! to be on the side of the angels for a change!

  We had previously changed all our left/right hand menus from tables into 'div's as part of our revised use of CSS so we now have nested 'divs'. However since not all our pages have been changed to the new layout this is necessary to allow for continued use of the current styles/layout. When the site is fully converted we only have to change a very small number of files (we use Apache SSI's) to remove this nested definition and in the meantime it is harmless on all tested browsers.

  Finally those still awake may have spotted that our normal left hand menu 'div class="n-l"' uses an attribute of 'fixed'. When we tried 'fixed' in both nested 'divs' ('l-l' and 'n-l') MSIE did not like it at all (very bizarre results) but all the browsers that support 'fixed' (Opera/Gecko) use the second (nested) definition to give a 'fixed' attribute. We also have a minor casualty in that the hover effect 'div.n-l a:hover {color:black;}' was lost by Opera in nested divs. Sigh.

• Center Pane:

  .l-c {
  	margin:0 160px 0 125px;
  	padding:4px;
  	font:10pt Verdana,Helvetica, Arial sans-serif;
  	border-width:0 1px;
  	border-style:solid;
  	border-color:silver;
  	[width:100%;]
  	}
  

  This is a normal 'in-line' element - position:relative is the default. This 'div' is browser-specific. Some browsers need the 'width:100%;' and some choke on it.

  The page actually worked perfectly well without the 'width:100%;' until we came to resize in Netscape 4.x when all kinds of bizarre things happened. Adding the 'width:100%;' attribute fixed NS 4.x. Then we re-ran the tests and MSIE took 100% literally! So add for Netscape, leave it out for MSIE and don't care for Opera and Gecko.

• Top Banner:

  In the first phase of conversion we left this as a table and let the 'l-c' div flow normally (postion:relative is the default) under this table. When we moved to CSS menus we had to place the banner in a position:relative div for Gecko and Opera browsers only (the only ones that support CSS menus) as shown below:

  .l-b {
  	height:45px;
    padding:5px 5px 0 5%;
  	}
  

  Essentially the div just positions the logo image inside the page and provides a bit of space. We left the MSIE implementation as a table because we we could not get the javascript positioning to work with pop-ups when using the div. So we have natural flow from 'l-b' through 'l-c' to 'l-f' with the two side menus being absolutly positioned. Worked great except we noticed that our CSS pop-ups did not pop-over the right menu div. To fix this we needed to give the 'l-b' div a higher z-index which in turns means that the div must be absolutely positioned (z-index only works with position:absolute). So we modified 'l-b' as shown:

  .l-b {
  	height:45px;
    padding:5px 5px 0 5%;
    position:absolute;
    left:0;
    top:0;
    z-index:9;
  	}
  

  This works well for Gecko but not Opera which seems not to like the fact that the google adds are placed last and continues to place the pop-ups under them. One day life will be perfect. But it also had the unfortunate effect of sliding the 'in-line' 'l-c' div up under the banner! So 'l-c' was modified as shown here:

  .l-c {
    margin:45px 160px 0 125px;
    padding:4px;
    font:10pt Verdana,Helvetica, Arial sans-serif;
    border-width:0 1px;
    border-style:solid;
    border-color:silver;
    [width:100%;]
  	}
  

  Addition of the top margin (45px) clears the banner header and means this div continues to be 'in-line' and importantly the following 'l-f' (footer) div flows to the bottom of the page as normal.

• Right Hand Menu:

  .l-r {
  	position:absolute;
  	top:60px;
  	right:6px;
  	width:150px;
  	[visibility:hide;]
    z-index:2;
  	}
  

  There are always casualties. This style absolutely positions the right hand menu with the 'right' attribute. This is a browser specific definition. Unlike the 'width' attribute Netscape 4.x does not have a buggy implementation of 'right' - it DOES NOT HAVE ONE. We're talking a serious NONE.

  We experimented briefly with 'left:92%;' etc. but it was just too messy and not accurate enough. We made a decision to start de-committing NS 4.x support from the site some months back. Sensible display but no new work. The quickest way out was to leave everything untouched and use 'visibility:hide;' to make the right hand menu invisible in our browser specific style sheet for NS 4.x. The right hand menu is there for everyone else except NS 4.x users. End of an era. Sad really.

• Footer:

  div.l-f table{
  	width:100%;
  	padding:4px;
  	}
  .l-f {
  	margin:0 160px 0 125px;
  	}
  .l-100 {
  	width:100%;
  	margin:0;
  	}
  <!-- HTML footer fragment -->
  <div class="l-f">
  <div class="l-100">
  <!-- footer table with no width - see selector -->
  </div>
  </div>
  

  These two crummy footer lines took the longest time - ain't that always the case. We had a footer which stretched 90% of the page and was nicely (well in our view) spread out in three columns.

  We started by wrapping our normal footer table in a null 'div' (border:0;). Worked perfectly except for short pages, when one or other of the left or right hand menus sat on top of it. We found a couple of articles that suggested that use of 'clear:both' in the footer div would place the footer below the longest absolutely positioned menu - we could not get this to work so we clearly have something that fights this fix - but we have no idea what it is.

  The obvious solution is to place the footer inside the central pane. But to keep the 'stretched out' look that we cherish (!!) there is a width="90% attribute and MSIE does nasty things with width inside a 'div'. Just blew the central pane to bits (kept wanting to write a whole screen width). Take out the width and we get the table 'scrunched' up in the middle of the page. So after hitting the web (seems almost nobody is using complex footers in 'table-less' designs) and a lot of experimentation we ended up with a nested 'div' solution and relative positioning - flows from the end of the 'l-c' div (both 'l-l' and 'l-r' menu divs are absolutely postioned). In spite of all this work NS 4.x still 'scrunched-up' the footer. Sigh.

---

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.